We use a process called ‘Test Driven Development’ in all our projects here at Bluefruit, and have done for many years now. Why? Because we believe that using this process has been a key factor in our high project success rate.
What is ‘Test Driven Development’?
TDD is a software development technique whereby a ‘unit test’ for the code is written before the functional code itself is written. Once these automated tests are written, they are tested (again, before any functional code is added) to make sure they fail, to show the test is working.
Once we know the unit test is working, we can add the functional code and test that. If it passes, the code is refactored (ie. tidied up), tested again, and the process is repeated for each feature. If it fails, the code needs to be tweaked and simplified until it does pass.
What is the traditional method of development?
Traditional software development takes a more linear approach, where the code is written first and then tested much later after implementation. This is often called the ‘waterfall’ methodology, which we’ve written about in more detail when comparing this to Agile.
What are the benefits of using TDD?
The problem with testing bulk amounts of code after its been written is that there’s no way to predict how changes or feature additions will affect the rest of the code, thus making it more difficult to scale or adapt. Using TDD means the code has been tested in smaller chunks (aka. unit tests) as it has been developed, so it’s a solid foundation for building upon or editing. It also means the code is generally cleaner and has less defects; in fact, in a recent OSDI paper, they found that the majority of production failures (77%) can be reproduced by a unit test!
The other main benefit of using this test-first approach is the fact that the developer receives immediate feedback on the code, and is able to spot defects quickly before moving on to refactoring.
How can you start implementing TDD today?
First of all, it’s important to educate your team about Test Driven Development and why it’s beneficial; this may involve hosting meetings where the practice is demonstrated, or by hiring a TDD consultant to come in and work directly with the developers.
The next step is to set some goals for TDD adoption and understanding what you’d like to achieve from the process, before trying out the TDD processes on a project to introduce it to your team and demonstrate it to others.
Have your team ever tried TDD? Share your experience in the comments!