Feel the Rhythm

TDD means you start by writing failing tests. It's a simple premise, but one I find people new to TDD do not fully appreciate. You need the red bar before you get the good feeling of a green bar. On its own, the green bar is empty and misleading.

It took a conversation with Steve Hayes before I really got it. Since then, I've been trying to pass the wisdom on, but in the end it is a journey of self discovery. I remember belaboring this point to my manager one day, though I felt the message wasn't hitting home. Then that week, he wrote a test that didn't fail as he expected it should (yeah, we let him write code from time to time) and I think he got it.

What prompted this is that today Jack and I were TDDing some new functionality. We'd written two simple tests for some filtering of HTML that we required. The first one tested that the source was not filtered when there was nothing to filter. The second test was a simple test to make sure that the first stage of the expected transformation in the filtering occurred.

We had a red bar, followed by a green bar for the first test and all felt good in the world. Then we had another red bar that was eventually followed by a green bar and everything was still good in the world. We realized to move forward, we expected attributes on the filtered tags and hence we needed to add a bit to the second test. (Que music of bad things to come, slow fade in.)

Our first step was to add the attributes to the test that just passed, thus writing a new failing test. Run test, green bar. Green bar!?! Between us, we worked out that an assertion that the team used didn't actually test what we were testing for in our HTML (Its a corner case we never really anticipated well, and not just adding attributes to any ol' tag.) (Que alarm bells ringing, loud and jarring)

Inspecting the assertion code, there are two comparison methods, one for most situation and one for the special situation we were testing (which we also discovered isn't used by a single test, not one, nada, zip, zilch, goose egg, ...). But we knew that the special situation doesn't work from our investigations into why we still were getting a green bar. (Que loud bomb raid siren)

We concocted a simple test by just changing one parameter in the normal compare that would cause the test to fail if it was in fact testing the special case. We ran the atomic tests and got a green bar. Yay so far. We ran the integration tests and started to see failing tests. In all, 131 tests have failed. (Que final bad conclusion dramatic music)

My initial impression was that when we wrote these tests, we weren't feeling the rhythm or the assertion was changed at a later date. I'm willing to bet that it is the former that we failed on.

Conclusion: no matter how confident you feel, you owe it to yourself, your partner (if you are fortune enough to be pairing), your team and your customer/employer to alway find that red bar. I don't care if you think the test tests what you expect it to, prove it with a red bar.

Corollary: If you are testing legacy code and your write a test, you'd expect it to pass, which is right, but remember to feel the rhythm and modify the part of the legacy code you think you are testing. No red bar on re-running the test means you're wrong and need to reconsider what you are doing.

Hopefully, you too will find the rhythm and make the your world a slightly better place to live...