Qualities of a Good Unit Test . . .

Cheese Pairing for this Post: smoked gouda
[this is something great for every day consumption; try some on toast]

So I was looking through some of the documents I have used for presentations in the office and I thought this was an interesting one:

A unit test should only test a small piece of functionality.
A litmus test is to ask if any part of the unit test could stand alone in a separate unit test.
Another feedback loop for your unit testing quality is the amount of time you spend with the debugger. If your unit tests are coarse, a test failure is more difficult to find. If the unit test exercises a small amount of code, the test failure cause can usually be spotted very quickly.

Order Independent & Isolated
There should never be an order dependency, intentional or not, between unit tests.
Problems arise when one unit test leaves some kind of dirty data lying around. Testing against a database or some sort of static cache is a common culprit.
Put evil, stateful things behind nice, deterministic mocks or stubs.

Intention Revealing
A unit test can, and should, be a valuable form of documentation.
Unit tests are part of the contract that software implements.
A unit test provides a sample of the expected usage of the code.
Excessive data setup can obfuscate a unit test beyond any hope of comprehension.

Easy to Setup
How easily can I set up an environment to run the tests? If the answer is "not very," I might never get the tests running.

As much as possible, decouple unit tests from external dependencies like databases and web services by using mocks or stubs. When you do test against an external dependency, the dependency better be setup correctly by the automated build.


Popular posts from this blog

Architecture at different levels of abstraction

TFS to SVN Conversion with History