Listen to this post
Ideally in TDD, no more than one test is ever failing at any given point in time. This test represents the work that is about to be done but hasn’t yet. Also, this test should not spend a long time in the red. We want the suite to get back to “all green” as quickly as possible.
Here are some reasons for this:
- To return to passing tests frequently, developers are encouraged to work in small steps. This reduces the likelihood of errors and also reduces the waste that task-switching can produce.
- Whenever the suite is all green, the code can be committed to version control. The longer you wait to do this the more likely you will be required to perform merge tasks, which have no real business value.
- It is the nature of daily business that we sometimes get interrupted. If we are forced to break away abruptly, then when we return later it may be hard to re-gather the context of the work we were doing. If tests had been all-green only a few minutes before the interruption, then “falling back” does not mean a lot of work will be lost.
Children are encouraged to eat in small bites and to chew their food thoroughly, so that they will not choke, rush, or overeat. Doing TDD in a small feedback loop follows this same principle.