I’m not refactoring, I’m test-driving new code, writing assertions first, yet I get two green bars in a row. Stop! I need to figure out what’s going on. The first possibility is that I didn’t expect to get green:
- Did I compile? Am I picking up the right version of the code? – D’oh!
- Does the test really specify what I think it does? – I take a bit of time to read through the test.
- Do I really understand the code well enough? – I dig into the code, and in rare circumstances fire up the debugger. Maybe someone wasn’t following YAGNI.
Alternatively, if I did expect to get green:
- Did I take too large a step? – I consider restarting from the prior red, looking for a way to take more incremental steps. Obviously a more-granular increment of behavior exists, since I felt to compelled to write a distinct assertion for it.
- Am I simply being completist? – I’m not testing, I’m doing TDD, where two greens in a row suggests that I don’t need the second assertion. Test-driving is about incrementally growing the system, not ensuring that everything works. But from a confidence standpoint, I want to probe at interesting boundary conditions. Sometimes my compulsion to probe is because I don’t understand the code as well as I should. Sometimes there’s just too much going on, and I find that adding confidence tests is worthwhile. And finally, I remember that my tests should act as documentation. So most of the time, I’m ok with being a “completist.”
- Are there “linked” (i.e. redundant) concepts in the design? – Maybe the interface is overloaded, deliberately so. More often than not, I can link the two concepts in the test as well, building a custom assert; conceptually I end up with one assert per test. If I find that I have a lot of tests with more than one postcondition, my designs are probably getting less cohesive. Or maybe I’m just writing too broad of a test.
There are no doubt other reasons for two greens in a row. No matter, the event should always trigger a need to stop and think about why.