Unit Testing

## The level, stated plainly A unit test is the narrowest automated check a codebase runs: it puts one piece of behaviour into a known starting state, invokes it, and asserts on the result. It is the only test level that is cheap enough to run continuously — after a keystroke, before a commit, on every push — and that economics, not any formal definition, is what actually shapes the rules around it. Three properties do the defining work. **Deterministic.** The same code plus the same test must produce the same verdict every time, on every machine, in any order, forever. A check that passes nine times in ten teaches the team to re-run rather than to read, and a level that is re-run rather than read has stopped being evidence. **Fast.** The working number is milliseconds per test, so that a suite of a few thousand finishes in seconds. Speed is not a nice-to-have here — it is the constraint that makes the feedback loop tight enough to change how people work. Once a suite crosses the threshold where an engineer alt-tabs away while it runs, it has quietly become a pipeline artefact instead of a design tool. **Localising.** When it goes red it should tell you roughly where to look without a debugger. A test that spans half the system may be perfectly correct and still cost an hour per failure, which is precisely why the narrow level exists alongside the wider ones. ## What is the unit? This is the part interviews actually probe, because the honest answer is *it is a decision, not a discovery*. There is no property of production code that marks where a unit ends. Two long-standing styles draw the line differently: - **Solitary** — the boundary is one class or one function, and every collaborator it reaches for is substituted with something inert. A failure can only come from inside that one type. - **Sociable** — the boundary is one cohesive *behaviour*, and collaborators that are in-process, deterministic and cheap are left real: a value object, a small formatter, an in-memory collection, a pure calculation. Only the collaborators that reach outside the process are substituted. Neither is wrong. They trade the same two goods against each other: how sharply a failure points at a line, versus how much the test survives a refactor that reshuffles the classes without changing the behaviour. A newcomer who insists 'a unit is exactly one class' is repeating a convention as if it were a law; the useful formulation is that a unit is *the smallest boundary whose behaviour a reader of the test can name in one sentence*. ## The lines that are not negotiable Whatever boundary you choose, some dependencies push a test out of this level regardless of how few classes it touches: - the **network** and anything behind it, - a real **database** or any shared store other runs also write to, - the **filesystem**, when the test depends on real paths, real permissions or files another run can see, - the **wall clock**, when behaviour changes with the date, the hour or a time zone, - **concurrency you have to wait for** — a background worker plus a sleep in the test body. Each of these buys either time or nondeterminism, and usually both. The usual remedy is not to add tolerance to the test but to move the dependency to a parameter: pass the instant in, pass the content in, hand the behaviour an abstraction it can be given a fixed answer for. That is why the level is so often described as design feedback — code that is awkward to test at this level is usually code that reaches for ambient state instead of receiving what it needs. ## What a good one looks like ```pseudocode test renewal_with_expired_card_is_marked_past_due: subscription = Subscription(status = ACTIVE, card = expiredCard) result = renewalPolicy.evaluate(subscription, at = INSTANT_2026_04_11T02_14Z) assert result.status == PAST_DUE assert result.reason == CARD_EXPIRED ``` One arranged state, one invocation, assertions on the promise the behaviour makes rather than on the steps it took to get there — and no ambient input at all: even the instant arrives as an argument. ## Where it sits The narrow level answers 'is this rule right?' It does not answer 'is the wiring right?', 'does the query really return that?', or 'does the assembled product work?' Those are genuinely different questions with their own levels and their own costs. What the unit level uniquely offers is volume: enough checks, cheap enough, to cover the combinatorial edges of a rule — the boundary values, the empty case, the negative amount, the duplicate — which no wider level could afford to enumerate.