One Page Intro To Microtests | Video

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 never *reaches* inside an object’s boundaries, though the tester may certainly *look* inside them.
• 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’. A developer is encouraged to commit anytime all microtests run green.
• 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 can be invoked 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.