The Specification Written in Proof
In the old way, Vichaar the scribe wrote requirements in prose. "The gate shall open when the correct key is presented. The gate shall remain closed when the wrong key is presented." The builders read the prose, built the gate, and declared it complete. Then the inspectors arrived, tested it, and found the gate opened for any key — because the builders had interpreted "correct" differently from the scribes. Three days of dispute followed. In the new way, Vichaar wrote the same requirement as a failing test: a precise, executable claim that when key-seven was presented, the gate must open, and when key-eight was presented, it must not. The test was the specification. There was nothing to interpret.
“A failing test is an executable specification. It is unambiguous in a way that prose never is.”
The Red Flag
Lohit the red flag appeared before any construction began. The test ran. It failed — not because anything was broken, but because the gate did not yet exist. This was the correct state of affairs. A test that passed before the gate was built was a useless test: it was testing nothing, measuring nothing, proving nothing. Lohit's red colour was reassuring. It said: "I am watching for something that does not yet exist. When it exists, I will turn green." The craftsmen celebrated the red flag. It meant the test was honest. Any builder who received a new test that was already green — before writing a single line of code — knew immediately that the test was broken and must be rewritten.
“A failing test is the starting condition. A test that passes before code exists is a test that proves nothing.”
The Laziest Gate That Would Do
Harit the green light taught the craftsmen a discipline that felt unnatural: build the smallest gate that makes the red flag turn green. Not the most beautiful gate. Not the most extensible gate. The gate that passed the test — nothing more. At first the craftsmen resisted. "But we know we will need a second gate soon," they said. "Should we not build the framework now while we are thinking about gates?" Harit was firm: "Build what is proven necessary by a failing test. Do not build what is anticipated." The discipline was uncomfortable but valuable: it prevented the endless complexity that accrued when builders built for futures that never arrived. Every line of code in the system was justified by a test that had required it.
“Write the minimum code to pass the test. Future needs are addressed by future tests. Speculation becomes technical debt.”
The Craftsman Who Did Not Change the Behaviour
Harit turned green. The gate worked. Now Nirmit the craftsman looked at what had been built. It worked — but it was rough. The wood was functional but unsmoothed. The hinge worked but was an improvised wedge. The locking mechanism worked but was a knot of rope. Nirmit improved each of these — smoothed the wood, fitted a proper hinge, installed a proper lock. After every change, he verified that Lohit remained green. The green flag was his guarantee: as long as it remained green, he had not changed the gate's behaviour — only the form of its implementation. The cycle was complete. Red: intention declared. Green: intention fulfilled. Refactor: form improved. Then red again, for the next intention.
“Refactor only when the tests are green. Green tests are the guarantee that refactoring does not change behaviour.”
The Design That Emerged from the Tests
After many cycles, something unexpected emerged. The gates built by the test-first craftsmen were easier to change than those built by the test-last craftsmen. The reason was structural: to write a test for a gate before building it, the craftsmen had to think clearly about what the gate needed to know, what it would receive, and what it would return. Any gate that was difficult to test was a gate with tangled responsibilities — it knew too much about its neighbours, it had too many reasons to change, it was impossible to isolate. The discipline of writing the test first forced the gate into a shape that was naturally modular. The design was a consequence of the tests, not their cause.
“TDD drives design. Testable code is loosely coupled code. The test forces the interface before the implementation.”
The Legacy Gate
One gate in the kingdom had been built before the test-first discipline arrived. It had no tests and was impenetrable to inspection. Adding a new test required understanding its entire interior first. Vichaar was called to help. She did not attempt to test the whole gate at once. She found one tiny, visible behaviour — a specific input that produced a specific, observable output. She wrote a test for just that behaviour. She did not change the code. The test passed. Now there was one verified fact about the gate. She added another test. Another verified fact. Slowly, around the untested interior, a harness of verified facts accumulated. The gate was no longer impenetrable. Change became possible, one fact at a time.
“For legacy code without tests, add tests for the smallest visible behaviours first. A characterisation test harness makes change possible.”
🪔 Deepak — the lamp of meaning · what this fable means in code
Test-Driven Development structures work in three phases: Red (write a failing test for a single small behaviour), Green (write the minimum code to make it pass), Refactor (improve the code while keeping the tests green). The cycle is short — measured in minutes, not hours. The discipline produces two outcomes: a complete test suite (every behaviour was driven by a test) and better design (testable code is decoupled code, because tight coupling makes testing expensive). In Vitest, `describe` groups related tests and `it` or `test` names the behaviour under test. When writing a test for code that does not exist, TypeScript will error at the call site — this is the compiler's version of the red flag. Acceptance-TDD (ATDD) extends the cycle: user stories become failing acceptance tests (Playwright or Cypress); those acceptance tests drive unit test cycles below them. For legacy code, the Characterisation Test pattern (also called the "golden master") documents existing behaviour without understanding its internals — sufficient to make change safe.

