Occasionally I’ll run into the situation where fixing a bug requires that I delete a section of code. The TDD purist would (I assume) advocate writing a failing test, deleting the code, then watching the test pass.
Now, it seems really strange to have a test asserting that some code was removed. Sure, I suppose it would ensure no one dug into source control and put that code back in, but is it worth it? If it is worth it, it certainly seems less valuable than writing a test for code that has been added, right?
2
You’re looking at it the wrong way. The test does not assert that code was removed. The test does assert a certain functionality.
The test does not care about the amount of code required to make it pass, nor does it realize that you have removed some code. The value of having such a test is the very same as any other test that you create due to a bug: you have confidence in the absence of the bug when the test passes and the test’s integration into the build process ensures you that the bug will most likely not be reintroduced.
Yet another way to look at it from a TDD perspective is the following: When you know that deleting the code fixes the bug and you then wonder whether to write a test, you already did TDD wrong. Once you start working on the bug you should first write the test that ensures the bug’s presence by failing. Only afterwards do you fix the actual bug – which may require removing code or not – and make the test pass. The question you are asking does not even arise in that way.
4