A good test is green whenever the UUT (Unit Under Test) is correct and is red whenever the UUT is incorrect.
There are 3 types of bad tests:
- Tests that are red when the UUT is correct and are also red when the UUT is incorrect. Obviously, tests of this type will be discovered immediately.
- Tests that are red when the UUT is correct and are green when the UUT is incorrect. This type of tests is worse than the previous type since it’s not always detectable. And if the UUT is incorrect (and thus the test is green…), it will provide you a false confidence that everything is OK.
- Tests that are green when the UUT is correct and are green when UUT is incorrect. This type is at least as bad as the previous type of tests. Tests like this are worthless.
The Red-Green-Refactor (RGR) path will most probably lead you to good tests in most cases. Why? If you follow that path, the first step is the Red step. In that step you should first write your test before the UUT is implemented (thus, incorrect). This almost ensures you that your test will be red when the UUT is incorrect. The second step is the Green step, in which you implement your UUT correctly and you expect your test to be green. This almost ensures you that your test will be green when the UUT is correct.
Eventually this leads you, with a high degree of certainty, to a ‘good test’ as described above (red when the UUT is incorrect and green when the UUT is correct).
Remember: we’re not talking about pure mathematics here, there will be times when you will follow the RGR path and still end up with ‘bad tests’. Yet, following this path will enhance the robustness of your tests dramatically.
Many times, people tend to write their tests only after they have completed the UUT and thus, skipping the Red step. This might lead them to bad tests of type 2 and 3 as mentioned.
My conclusion: follow the RGR path.