Graham King

Solvitas perambulum

Keep your unit testing lazy

software
Summary
Oscar Huseyin argues that while thorough unit testing and TDD can improve code quality, striving for 100% code coverage can lead to unnecessary pressure and inefficiency. He suggests a pragmatic approach, emphasizing the importance of writing just enough tests to ensure functionality without overwhelming oneself or inflating costs for employers. By focusing on designing code for testability and selectively testing key components, developers can strike a balance that maximizes value rather than pursuing perfection. Ultimately, the goal should be effective simplicity rather than strict adherence to testing dogma.

Oscar Huseyin, via JavaLobby, has an interesting post on how much unit testing is good:

Over the years, l’ve read lots of commentary, white papers, best practice papers, books on the topic of TDD. I’ve heard the rant of many TDD evangelists who preach about how total code coverage brings you closer to code quality perfection and how you’ve failed when you’ve not been able to achieve these goals. Sure, this is an extreme example of evangelical preaching, where in actual fact, most of these individuals commonly drum down their hard line views of testing by using words like “pragmatism” and statements like “do what works best”. But, why do l feel as if I’ve failed if l have not got 100% code coverage? It’s because l, to some degree, shared some of the religious views about testing.

This echoes my feelings in TDD. Beyond a certain level, the cost of testing seems to outweigh the benefits. Yet, when I didn’t have a high code coverage I felt I was somehow failing myself, or my community. Then I’d add more tests, feel good about myself, then realize I was charging my employers for an ego boost, not for software they wanted. Oscar concludes:

My view is simple. We all need to be pragmatic about how we approach our unit testing. We should always stop and ask ourselves “are we going to far with our unit testing?”. As a developer, we are faced with this question constantly. We should always do the most to prove our components are functionally correct, but also write the least amount of unit test code to ensure our testing solution remains simple yet effective. After all, a good developer is a lazy one.

Most practitioners of TDD have probably by now found a middle ground of what I’ll call Just Enough Test Driven Development. Stop feeling bad about it and turn the middle ground into a happy medium – you’re optimizing for value not for religious adherence. If you have to get religious, may I suggest the more ancient and established religion that Oscar mentions:

The three chief virtues of a programmer are: Laziness, Impatience and Hubris — Larry Wall

TDD evangelists say that it isn’t about testing, but about design. That is where the biggest gains are to be made. So design all your code as if you were going to test it, then only actually write the tests for the key components, and key methods of components.

Happy Coding!