One Page Intro To Microtests

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.

 

Leave a Reply

Your email address will not be published. Required fields are marked *