I just threw away a bunch of tests
I had failed to complete the "refactor" part of "red/green/refactor" several weeks ago, leaving me with some redundant tests that came back to bite me.Yesterday I just deleted a whole bunch of tests in a project I’m working on for a client.
Why? Aren’t tests supposed to be helpful?
Supposed to be, yes.
And these tests were helpful, once.
The thing is, I had written these tests while using Test-Driven Development, so I know that they had been valuable at the time they were written. So what changed?
What changed was a refactoring several weeks ago. The functionality these tests covered had been extracted to a new Go package (class in OOP parlance). When I extracted that functionality, I did it using TDD, so I wrote new tests in the new location, and the existince of the old tests in the old location served as proof that I didn’t break anything in the process.
However, I had failed to complete the “refactor” stage of “red/green/refactor”, and left the old tess in place. During my refactor, I had written a test, saw that it failed, then wrote/copied the code to make it pass. What I missed was the part of refactoring that removes duplicate code—and tests are code!
I noticed yesterday when I made a change, and it broke more than one test. Oops. The old tests and the new tests both started failing.
So I fixed the new test, and deleted the old, now-duplicate test.
One charactaristic of a good test is that a single failure will trigger a single test. It’s not always achievable, but when you see more than one test failing for the same bug, it’s definitely a smell, and something to consider. It often requires more thought than just deleting a duplicate test, but that’s an easy place to start looking!