I just read a post over at proggit titled “Can Unit Testing be a Waste?”.  The basic argument was that unit testing should go at the problem from a high level of abstraction, and you shouldn’t worry about going after every low level method in your DAO classes, or your User model.

One of the ways the author used to justify his argument was an example in Java that testing the high level got an overall coverage amount in the 95+% range.  This is a misleading number.

The goal of unit testing is not to run your code, that only shows that you compile, and don’t blow up.  At best it’s a form of smoke testing.  The goal of unit testing is to ensure that your unit works as expected, and because you’re so close to the unit, you’ll be able to setup the environment (and mocks) to simulate issues and problems.

Then you verify using the various asserts.

My argument against using the highest level of abstraction is that you give up some of the core benefits of unit testing, namely the ability to really dig into your implementation and identify edge cases, and error situations.

Before I get yelled at, I know that going too low into the nitty-gritty ties your unit tests too closely to your code, which negates many of the “safety net” features that make refactoring easy.  Honestly, what I think was being described in the “Can Unit Testing be a Waste?” post was integration (or feature, or validation, or whatever term you like) tests, not unit tests.

Stop getting sidetracked by coverage, focus on what bugs are being exposed by your test code, and focus on the benefits you get from writing the test case.

This entry was posted on Thursday, August 28th, 2008 at 7:57 pm and is filed under Programming, Rant. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.