The Six Minute Guide to Useful Unit Tests.
The biggest problem with unit tests are their name. Engineers will argue for ages about what a “unit of work” really is. Articles about how to do unit testing well all start with defining a unit of work, and it’s a shame — because it doesn’t fucking matter.
Unit of Work doesn’t help engineers produce more value. It does not make their lives easier. And after some twenty years writing unit tests, it’s often counter-productive guidance. It doesn’t help you achieve your goal.
But what is the goal here? It is not making sure that your code is correct. That is not what tests do. All testing is about risk mitigation. The goal of software testing in particular has two parts:
- Reduce the risk that you made a mistake writing the code.
- Reduce the risk when people change the code.
That’s it. There are of course many ways to achieve these goals. Unit testing is just one particular technique. Sometimes other techniques will be more useful. Keep an open mind.
Cool, on to the meat of it all. What differentiates unit testing from other techniques is isolation.
The theoretical ideal is that there is a 1:1 ratio between unit tests and potential mistakes in the software. One mistake can cause one and only one test to fail, and that test…
