Many developers develop the healthy habit of Test-driven Development (TTD). This practice, inherited from Extreme Programming (XP), is the process of splitting each development stage into small steps and then writing a failing test for every one of them. You make the necessary modifications so that the tests pass again (test are green). You can then refactor your code as long as the tests remain green. The following figure illustrates the TDD cycle:
You can iterate until the feature is done with very short feedback loops, with the insurance of no regressions, and the guarantee that all the code you write will be tested from the very beginning.
TDD gets its share of criticisms. The most interesting ones are these:
- It takes more time to write the tests than to do the actual implementation
- It can lead to poorly designed applications
The truth of the matter is that it takes time to become a good TDD practitioner. Once you get the feeling of what should be tested and know your tools well enough, you won't lose much time at all.
It also takes experienced developers to craft an application with a proper design using TDD (or with any other methodology). Poor design can be a side effect of TDD if you get trapped in the baby steps mantra and forget to look at the big picture. It is true that TDD won't magically lead to great application design, so be careful and remember to take a step back after completing each feature.
From the beginning of the book, we have only had one autogenerated unit test in our code. This is bad! We didn't follow good practice. This chapter is here to address this problem.