Unit Tests are Tests
James Carr writes:
Unit Tests are NOT “tests” in the classical sense… they instead should be used to drive your design, to help you think about how the system you are writing should work, to illustrate functionality.
I disagree with the all caps “NOT”. I think unit tests are primarily for testing, and are particularly valuable for regression testing. I do find that writing tests as I write code influences and usually improves design, but they certainly are “tests”. The fact that tests can drive your design and illustrate functionality are often nice side effects, but they are not the primary reason I write tests.
He goes on to write:
If you ever find yourself running a code coverage tool after writing fresh code, step back and realize that you’re doing it wrong.. my suggestion is if you run a code coverage tool and find parts of your freshly written code aren’t covered, delete that code and try again.
Deleting and rewriting code is a bit too extreme for my taste, but I often do something similar. When fleshing out new work, I’ll often write new classes and interfaces, bounce ideas off coworkers, and rename / refactor heavily. Once I feel like I’ve found the right approach, I will sometimes comment out blocks of code, write a quick unit test (that fails), and then replace the code.