Red, Green, Refactor as Delivery Discipline

Test-first development is sometimes reduced to a preference about when a test file is written. The important distinction is stronger: a focused test must first demonstrate that the requested behavior is absent. That observed failure gives the test meaning. It shows that the assertion can detect the gap it is supposed to protect.

The red step should be narrow and legible. Name one observable behavior, use the public interface, and confirm that the failure comes from missing behavior rather than a broken import or typo. If the test passes immediately, it may be describing existing behavior or asserting too little. If it errors before reaching the assertion, repair the test harness until the failure explains the real gap.

Green is deliberately modest. Add the smallest production change that satisfies the test, then run the same command and read the result. This constraint discourages speculative options, unused abstractions, and future-facing configuration that nobody has requested. Once the behavior is green, refactor names or structure while keeping the evidence intact.

This loop scales beyond algorithms. A content catalog can prove exact records, unique slugs, safe links, and bounded article lengths before the data exists. A component test can establish heading semantics and keyboard focus before styling begins. A security route can start with rejected malformed input before accepting a valid request.

The result is more than coverage. The tests become executable acceptance criteria, and the sequence records that they were capable of failing. That discipline makes review easier because implementation and evidence move together. It also makes future change safer: when a contract shifts, the failing test identifies which expectation needs a deliberate decision rather than an accidental edit.