Last month on the 37signals blog, DHH wrote about testing like the tsa. In the article David argues for less strict test driven development and quotes Kent Beck in saying:

I get paid for code that works, not for tests, so my philosophy is to test as little as possible to reach a given level of confidence (I suspect this level of confidence is high compared to industry standards, but that could just be hubris). If I don’t typically make a kind of mistake (like setting the wrong variables in a constructor), I don’t test for it.

At Highgroove, we feel this approach is not for everyone. Read on for more details on our approach.

While it may be true that after years of working with automated testing you may not need to aim for 100% coverage, your instinct for what needs to be tested and what does not comes from experience. Complete test coverage of your codebase may be overkill, but generally more tests are better than fewer.

For most of us, developing with tests is a process that changes over time. Less experienced developers should aim for full coverage using integration and unit tests. As a developer learns to write tests, they get a sense of when writing a test is too hard or is taking too much time. Nine times out of ten this will mean that the code you are trying to test is poorly designed and needs to be refactored, not that you shouldn’t be writing a test.

Test driven design is one of the most powerful tools in a developer’s arsenal and most of the time you are not testing enough instead of too much. Overall, developers need to experiment to see what makes them most effective, not just follow rules laid out in a blog post. 😉

Image credit: DaveBleasdale