An interesting essay about unit testing.

I rarely see much discussion of unit tests that acknowledges that they may not be appropriate in some contexts. But the cost/benefit function for unit tests is by no means trivial:

• For many kinds of code, building worthwhile unit tests is extremely difficult. In my experience, the sophistication of the unit test code matches the sophistication of the code it tests. For code with a simple synchronous interface, and where the outputs are a simple deterministic function of the inputs, unit testing will be easy. When these conditions don't apply (that is, for code that is hard to get right), unit testing can become much more difficult.

  Even for "hard" code, unit testing is still possible, but the design must respect unit-testability. This can greatly increase the amount of work involved over the non-unit-tested case. If this level of difficulty is underestimated, the tests may end up ensuring very little, or being fragile, or creating an obstacle to maintainance and further development of the code covered by the tests.

• In a large OO program, much of the behaviour arises from the interactions between objects. Unit testing strives to test individual classes, and so does not help to find problems in these interactions. At best, it can ensure that the objects implement their sides of the relevant contracts correctly. But that may not mean very much in a design where groups of objects achieve more than the sum of there parts.

Because of issues such as these, unit testing might best be understood as a way of catching some bugs earlier, rather than as a way to reduce overall defect rates. Thus it can make the development process more predictable.

But comprehensive unit testing has high costs, and other forms of testing may be more appropriate for some projects, or some parts of some projects. It would be nice if there was less cheerleading of unit testing, and more analyis of the pros and the cons.