Unit Test - Definition

I used to feel that a ‘unit’ was the smallest possible part of a code base (a method, really). But in the past couple of years I’ve changed my mind. Here’s how I define a unit test, as of October 2011:

A unit test is an automated piece of code that invokes a unit of work in the system and then checks a single assumption about the behavior of that unit of work.

A unit of work is a single logical functional use case in the system that can be invoked by some public interface (in most cases). A unit of work can span a single method, a whole class or multiple classes working together to achieve one single logical purpose that can be verified.

A good unit test is:

Able to be fully automated

Has full control over all the pieces running (Use mocks or stubs to achieve this isolation when needed)

Can be run in any order if part of many other tests

Runs in memory (no DB or File access, for example)

Consistently returns the same result (You always run the same test, so no random numbers, for example. save those for integration or range tests)

Runs fast

Tests a single logical concept in the system

Readable

Maintainable

Trustworthy (when you see its result, you don’t need to debug the code just to be sure)

I consider any test that doesn’t live up to all these as an integration test and put it in its own “integration tests” project.