Test doubles without a framework

A function that reads the clock gives a different answer at nine in the morning and at nine at night. A function that picks a random number gives a different answer every time. A function that sends an email produces nothing you can inspect and something you very much do not want happening a hundred times while a test suite runs.

In all three cases the trouble is the same, and it is worth naming precisely: the function reaches out and gets something the test cannot control, or pushes something out where the test cannot see it. Not one of those is a bug in your testing - it is a shape problem in the code, and the fix is to change the shape.

A test double is the stand-in you hand the code instead of the real thing: a clock that always says the same time, a sender that quietly writes into an array. The word comes from the film industry, where a stunt double stands in for the actor in the one scene that would be dangerous or impossible to shoot for real. Same job here - and, as in film, the double is only convincing for that scene.

There is one move that makes almost anything testable, and it is embarrassingly simple: whatever the function reaches out for, make it an argument instead. A function that calls the clock becomes a function that takes a now argument. A function that sends becomes a function that takes a send argument. This is called dependency injection, and the impressive name describes a change you could explain to a child.

In real use the caller passes the real clock and the real sender, so nothing about production behaviour changes. In a test you pass a function that always returns the same timestamp and one that records what it was given. Now the test controls the input completely and can see the output completely, which is the entire requirement for a test that means something.

There is a bonus you did not ask for. Code written this way is easier to reuse, because the function no longer insists on one particular clock or one particular sender - and it is easier to read, because everything it depends on is listed in its parameters instead of hidden three lines down. The habit of making dependencies visible pays for itself long before the tests do.

A stub answers. It exists to give the code under test a fixed reply so that the interesting behaviour can be reached: a clock that always says noon, a lookup that always returns the same customer.

A spy records. It exists so the test can afterwards ask what happened: how many times were you called, and with what? A spy is usually a function that pushes its arguments into an array you can read later, which is exactly what you will write in the exercise.

A fake works, simply. It is a real, small implementation standing in for a large one - an in-memory array where the real thing is a database. It behaves correctly for the cases you care about and cuts every corner you do not.

The vocabulary is not standardised: some frameworks call all three mocks, some draw the lines elsewhere, and the arguments about it are not worth your time. What matters is the question each one answers. Am I feeding the code a reply it needs (stub), am I checking what the code did to the outside world (spy), or am I substituting a working part (fake)?

The first mistake is asserting that a spy was called and stopping there. 'notify was called' is nearly free information - it is 'notify was called once with grace and the shipped message' that would have caught the bug where every customer got the wrong text. If a spy is worth having, assert on its recorded arguments.

The second is doubling too much. Replace every dependency of a function and the test no longer touches anything real; it checks that your stand-ins were used in the order you wrote them, which is a test of the test. A useful rule of thumb: double the things that are slow, unpredictable or have real-world side effects, and let plain data and plain functions be themselves.

The third is the sneakiest. Doubles freeze an assumption about how the real thing behaves. Your fake sender never fails; the real one does. Your fixed clock never crosses midnight; the real one does, at midnight. When a double and reality drift apart, every test still passes and the product is broken - which is why the interface you are doubling should be small enough that you can hold its real behaviour in your head.

If a function reaches out for the clock, randomness or the outside world, the test cannot control it - so pass that thing in as an argument instead. A stub answers, a spy records, a fake works simply. Assert on what the spy was called WITH, not merely that it was called. And keep the doubled surface small, because every double is an assumption about reality that nothing will re-check for you.