AI Wisdom
🪷Proof Tale IV

The Test Before the Deed

A Panchatantra fable about Test-Driven Development

📖
Story · +20 XP
8 min read · 6 sutras
🎭 The Cast
  • LohitThe red flag — the failing test that declares the desired behaviour before it exists
  • HaritThe green light — the simplest possible code that makes the test pass
  • NirmitThe craftsman — refactors the passing code without changing its behaviour
  • VichaarThe specification scribe — writes the requirement as a failing test rather than a prose document
6 sutras~8 minWith reflectionMaps to RAG concepts
Begin the tale
Sutra Pratham
1
Scene 1 of 6

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.

⚜ The Moral ⚜
A failing test is an executable specification. It is unambiguous in a way that prose never is.
Sutra Dwitiya
2
Scene 2 of 6

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.

⚜ The Moral ⚜
A failing test is the starting condition. A test that passes before code exists is a test that proves nothing.
Sutra Tritiya
3
Scene 3 of 6

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.

⚜ The Moral ⚜
Write the minimum code to pass the test. Future needs are addressed by future tests. Speculation becomes technical debt.
Sutra Chaturtha
4
Scene 4 of 6

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.

⚜ The Moral ⚜
Refactor only when the tests are green. Green tests are the guarantee that refactoring does not change behaviour.
Sutra Pancham
5
Scene 5 of 6

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.

⚜ The Moral ⚜
TDD drives design. Testable code is loosely coupled code. The test forces the interface before the implementation.
Sutra Antim
6
Final scene

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.

⚜ The Moral ⚜
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.