Two Greens in a Row

by Jeff Langr

March 11, 2009

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.


Jake Dempsey March 22, 2009 at 07:34am

I have found that I often make two dumb mistakes while tdd’ing. I am using Ruby’s unit testing framework on a project, which is very similar to Junit 3.8. I often times forget to puts test_* as my test name and after writing what seems to be a failing test, I run my test and nothing….all green…wtf?!? I have spent 10 minutes looking at a test thinking…there is no way that can be green.

The other one I do a little less frequently, but still fall prey to it is using the wrong assertion. I have sometimes says “assert foo, bar” instead of “assert_equal foo, bar”. The first will always pass as long as foo is an object.

There are a ton of these I’m sure.

Share your comment

Jeff Langr

About the Author

Jeff Langr has been building software for 40 years and writing about it heavily for 20. You can find out more about Jeff, learn from the many helpful articles and books he's written, or read one of his 1000+ combined blog (including Agile in a Flash) and public posts.