Uncle Bob’s rules for TDD are specified here.
- You are not allowed to write any production code unless it is to
make a failing unit test pass. - You are not allowed to write any more
of a unit test than is sufficient to fail; and compilation failures
are failures. - You are not allowed to write any more production code
than is sufficient to pass the one failing unit test.
But, is it ok to write a bunch of tests that pass as soon as the test compiles? For example, a test that asserts null and the default impl of a method I’m testing returns null. Am I doing something wrong by doing this? Should I skip to the first test that will fail or is it ok to write tests that automatically pass first?
1
No, because it is possible to write a test that inadvertently passes when it should actually fail.
That’s why you must make it fail first, so that you can demonstrate transitioning from a failed state to a passed state where you’re testing the actual functionality that you want, rather than having a bogus test that passes and makes you think that your code actually works, when in fact it doesn’t.
7
It depends.
If you are writing software to solve a business problem or produce a useful tool, then yes, you are allowed to write a test that passes automatically.
If, on the other hand, you are writing software in order to perform a religious observance at the First Denominational Church of TDD, then no, you are not allowed to do that. And you should probably take a moment of self-flagellation for even asking the question.
6