ronin

Elliotte Rusty Harold responds to Charles Miller’s post about writing an anti-test:

That’s a recipe for disaster if I ever heard one. Five years down the line some new programmer is going to finally fix the line of code that causes the bug, and then carefully reintroduce the bug to get back to the green bar.

I have to disagree. As Charles states

Make sure you annotate it with the issue that it’s verifying. That way your continuous integration environment will let you know immediately if something’s suddenly worse than it was before.

5 years after you write the test, the lucky programmer who’s going to fix the problem gets a present, a little bit of context and knowledge about the intended behaviour. If annotated with enough context, maybe a decent text description in the assertion and some documentation around the test code, it should be clear enough what’s going on. If it doesn’t apply anymore the test can be fixed, removed, or whatever makes sense.

Keeping the Bar green all the time is impossible, and undesirable really. On your machine hovering between red and green is healthy, to me it shows I’m making progress. I also like seeing the number of tests climb. Keeping the bar green in a CI build is also impossible, but that’s why we do CI, to integrate and find the problems and in my experience if the build stays red for too long developers are less likely to try and fix the problems because “the build is always broken”.

Actually, maybe I agree with both Charles and Elliotte?