Beyond test coverage
We first set off by requiring a 95% coverage before commit. This was a bit a pain in the ass but it was basically doable. This made sure all features in the system had tests, it’s simple not possible to commit anything without tests when you set the bar as high as this. But this is doesn’t necessarily it’s test-first development, it’s just tested development.
I love test coverage tools.
Another team at work was working on deciphering and robustifying a hairball project by slowly retrofitting tests and refactoring. Each day they managed to push the Clover bar a tiny bit higher and it served as a goal. Today we’ll get it to 20%, 30%, 90%….
Unfortunately coverage tools can also be misleading. It’s easy to write code that covers the lines of code but doesn’t actually test them. A complementary approach is to use code mutation tools such as Jester - The Test Tester.
Jester takes a class and a testcase and runs the tests to check they all pass. It then makes tiny changes to the class under test, one by one, and reruns the tests each time. If the lines of code are tested properly, every little change should cause at least one test to fail. If the tests still pass it notifies you that you are not testing that line properly.
Although it’s harder to use Jester and not typically something I’d do everyday, it has told me some very interesting things no other tool has pointed out about my code. Aside from pointing out lines of code that my tests execute but don’t actually test, it has also pointed me to flawed algorithms that can be greatly simplified.
Ivan Moore has written some good stuff on the subject here and here.