The Acrobat Who Trusted Nothing
Vyoman the acrobat refused to perform without a net below him. Not because he feared falling — he had never fallen — but because the act required trust, and trust required proof. "Tell me that every knot holds," he said to Jaalin before each performance. Jaalin the net weaver understood. The net had ten thousand knots. To test the net as a whole was impossible before a performance. But to test each knot individually, in isolation, was entirely possible. Pariksha the inspector moved methodically. She pulled each knot. She applied weight. She noted the result. If a knot held, she moved on. If a knot failed, she cut it out and replaced it before it was ever part of the net.
“A large system is trustworthy only when each small unit within it has been individually verified.”
The Three Phases of the Inspection
Pariksha had a method she called Prepare, Act, Assert. First, she arranged the knot exactly as it would be in the net — isolated from its neighbours, under no external forces. This was Prepare. Then she applied the stress the knot would face in the act — a pull of a defined force in a defined direction. This was Act. Finally, she observed the result and compared it to what she expected: the knot should hold; the rope should not fray; the diameter should not change. This was Assert. The method was strict. One phase could not bleed into another. If Pariksha prepared and acted simultaneously, she could not trust the result. If she asserted before acting, she was measuring nothing.
“Arrange, Act, Assert. Each phase must be distinct. Mixing them produces a test that cannot be trusted.”
The Knot That Needed No Neighbours
A young apprentice asked Pariksha why she tested each knot away from the net, not within it. "When knot three is inside the net, it is affected by knot two and knot four," Pariksha said. "If it fails, I do not know whether knot three failed or knot two altered knot three's behaviour. I need to know that knot three fails or passes on its own terms — with no help from its neighbours and no interference from them." She called this isolation. A test that required the full net to run was not a unit test. It was a system test, and system tests found different problems in different ways. Unit tests found that knot three had been tied incorrectly — regardless of who tied it, when, and what surrounded it.
“Isolation is what makes a unit test a unit test. Without it, you are testing a system, not a unit.”
The Stand-In That Held Its Position
Some knots required nearby rope segments to form their shape. Pariksha could not test those knots without some neighbouring context — but she could not use the real neighbouring rope, because the neighbouring rope's behaviour would confuse the measurement. So she used a stand-in: a piece of rope that behaved exactly as specified — always taut, never fraying — so that knot three could be tested in isolation while still having the adjacent shape it needed. The stand-in made no decisions of its own. It simply held its position and returned what Pariksha told it to return. When knot three failed in this setting, she knew it was knot three that failed, not the stand-in.
“A test double holds its position so that the unit under test can be observed without interference.”
The Net That Could Be Changed Safely
Years passed. The act changed. New tricks required new net shapes. Every time Vyoman's choreographer proposed a new configuration, Jaalin felt no fear. She changed the knots, and Pariksha re-ran the inspection. Each knot reported its result in seconds. If three thousand knots passed and one failed, Jaalin knew exactly which knot she had broken and exactly what behaviour had changed. She fixed it in minutes. The act was ready the same morning. Other circuses spent days testing new configurations because they had no knot-level inspection — only a full dress rehearsal that took hours and reported "it broke" without telling them where.
“Unit tests are not a cost. They are the mechanism that makes change affordable.”
The Knot That Always Behaved the Same Way
Pariksha's final rule was determinism. A test that returned different results on different days was not a test — it was a weather forecast. She forbade any knot test from depending on the time of day, the ambient temperature, or the mood of the market outside the tent. She said: "A test must return the same result whether run once at dawn or ten thousand times at midnight." Where a knot's behaviour depended on time, she froze the clock. Where it depended on randomness, she fixed the seed. Determinism was not optional. A flaky test was worse than no test — it trained inspectors to ignore results, and an ignored result was a missed failure.
“A deterministic test is a trustworthy test. Non-determinism teaches inspectors to stop looking.”
🪔 Deepak — the lamp of meaning · what this fable means in code
Unit testing isolates the smallest testable piece of code — a function, method, or class — and verifies its behaviour without dependencies on the file system, network, or database. The AAA pattern (Arrange-Act-Assert) structures each test: Arrange sets up inputs and state; Act calls the unit under test; Assert verifies outputs and side effects. Test doubles (stubs, spies, mocks, fakes) replace real dependencies so that a failing test unambiguously points to the unit under test. In Vitest, `vi.fn()` creates mock functions; `vi.spyOn(obj, "method")` wraps real methods. Determinism is enforced by avoiding `Date.now()`, `Math.random()`, and network calls — use `vi.useFakeTimers()` and controlled fixtures instead. The payoff: unit tests run in milliseconds, give immediate feedback on regressions, and make refactoring safe by encoding expected behaviour as executable specifications.