I would like to offer the agile and XP communities a new word for an old idea: Microtest instead of Unit Test.
My rationale for this suggestion is straightforward. Unit test already has a meaning out there in the development world, and that meaning doesn’t match the agile/XP meaning. There are several aspects of an ordinary microtest that can be entirely absent from a normal unit test. Traveling around as I do, I get to work with an enormous number of teams, and I can tell you from extensive experience, teaching people about XP style testing is notably easier when we don’t have to repurpose a word that’s already in play.
A microtest has the following properties:
- It is short, typically under a dozen lines of code.
- It is always automated.
- It does not test the object inside the running app, but instead in a purpose-built testing application.
- It invokes only a tiny portion of the code, most usually a single branch of a single function.
- It is written gray-box, i.e. it reads as if it were black-box, but sometimes takes advantage of white-box knowledge. (Typically a critical factor in avoiding combinatoric issues.)
- It is coded to the same standard as shipping code, i.e. the team’s best current understanding of coding excellence.
- It is vault-committed source, with a lifetime co-terminous with the functionality it tests.
- In combination with all other microtests of an app, it serves as a ‘gateway-to-commit’. That is, a developer is encouraged to commit anytime all microtests run green, and discouraged (strongly, even nastily) to commit otherwise.
- It takes complete control of the object-under-test and is therefore self-contained, i.e. running with no dependencies on anything other than the testing code and its dependency graph.
- It runs in an extremely short time, milliseconds per test.
- It provides precise feedback on any errors that it encounters.
- It usually (not always) runs entirely inside a single computer.
- It usually (not always) runs entirely inside a single process, i.e. with few extra-process runtime dependencies.
- It is part of a collection all or any subset of which is invokable with a single programmer gesture.
- It is written before the code-change it is meant to test.
- It avoids most or all usage of ‘awkward’ collaborators via a variety of slip-and-fake techniques.
- It rarely involves construction of more than a few classes of object, often one or two, usually under five.
Over the years I’ve had some pretty comedic conversations with people. One fellow was quite irate and insisted that the list above was just the definition of a good unit test. Maybe microtest just means good unit test.