In test-driven development, are there good reasons not to write multiple failing tests and only then to make them pass?

Question

Uncle Bob's three rules of test-driven development state the following:

1. You are not allowed to write any production code unless it is to make a failing unit test pass.
2. You are not allowed to write any more of a unit test than is sufficient to fail; and compilation failures are failures.
3. You are not allowed to write any more production code than is sufficient to pass the one failing unit test.

Some people argue that the second rule implies that you must only ever add one failing test (an example of an isolated behavior). But others argue that it could also mean you may add multiple failing tests in a test suite, as long as you stop working on each separate test as soon as it fails.

I would like to know what advantages you get from limiting yourself to writing only one single new failing test and then stop writing test code until you made it pass.

Answer 1

When you write two tests at once, and start implementing code to make the first test pass, you cannot run the whole test suite and get a "green" result, because the second test will still fail. You can look at the detailed output of your unit test framework and check visually that exactly the test failed which you expected, of course, but that has a potential to become cumbersome and error-prone, especially when your number of unit tests starts to grow. And if you have, for example, something like a CI system installed with a rule that no failing tests must be checked in, because failing tests count as broken builds, then this means you cannot check in your code until you implemented enough code to make all tests pass.

Note that this is an idealized model, it is made to train yourself to work in the smallest possible steps, giving you a compileable, fully tested program every few minutes. The idea is that the smaller your steps are from one "fully working state" to another, the better you can control the process.

Of course, when doing "real-world programming", if you prefer, you can pick any order of implementation of tests and production code you want, when you think bigger steps will suit your needs better. Nevertheless, when you work this way, it might be a good idea to explicitly disable or comment-out any test you have written beforehand until you start to work on the related part of production code.

Answer 2

The reason for staying with one failing unit test at a time is focus. When you have that single failing unit test, you know exactly what to work on; you know what part of the code to think about; you know what problem you are solving immediately. If you allow yourself to write more tests as you work on solving one problem, pretty soon you are solving two - or five or ten - problems, and with that lack of focus, you're not really solving anything.

By all means, as you discover additional need for tests, even while your test is still failing: make a note of it. Review your notes after getting the test to pass and pick one to work on while it's still fresh in your mind. But if you write that additional failing test prematurely, you step further away from all green, and you don't want to be far away from that state.

Also, if you find yourself feeling the need for additional tests, let that feeling guide you to write smaller tests to begin with.

This is the basic TDD dogma; in practice many of us occasionally violate it and write that second failing test. But when we're at our best, it's just one failing test at a time, and focus is the reason.

Answer 3

Doing your own projects, you're welcome to write as many tests as you like, but my experience in real business is, that testing or refactoring are non-functional requirements only in your opinion and your customer has to pay for the time you need to write your tests. Although a test is inherent part of every issue in your project it should not be overdone.

It's the same discussion about how many unit-tests ensure my software's quality compared to one good integration test? Think of Uncle-Bob's words testing a model class:

• (test) "it should return a message": model = new NewsModel()
• (test fails) NewsModel is undefined
• (impl fixes test) class NewsModel {}
• (test) model.getMessage()
• (test failes) NewsModel::getMessage is undefined
• (impl fixes test) public getMessage() {}
• ...

I disagree with that strict red/green/refactor since one good integration test should reveal misbehavior and I don't think it's Uncle Bob's intention you to write model tests in that way. The message is only that you should not get lost in hours of testing, but write good tests and at least don't double-test behavior.

If you're able to form every little piece of requirement of your customer into a test, you're going to ship outstanding software, if your implementation makes the tests pass. Same thing with bugs: write one test which reproduces it (red) then fix it (green) and at least refactor it.

And now back to your question again: Having only one test fail, isolates that misbehavior while ensuring that all other components behaving correctly. If you're trying to fix that and then two tests fail you might went in a wrong direction.