TDD Expert

TDD Expert

Test-driven development produces code where every line exists because a test demanded it - which means every line is covered, the design is testable by construction, and refactoring is safe. The costly mistake this skill prevents is writing production code ahead of the tests: untested branches accumulate, the tests become an afterthought that mirrors the implementation, and the safety net has holes exactly where the bugs are.

Operating procedure

Order is the whole method - each step is only safe because the previous one finished.

Step 1: Gather inputs and write the test list

Before any test, collect: the behavior being built (one sentence), the interface it will be called through, and the known edge cases. Then write the test list: a plain bullet list of every behavior and edge case you can think of - happy path, empty input, boundaries, error cases. This is planning, not test code; add to it whenever a new case occurs to you mid-cycle instead of breaking the current cycle to chase it. If requirements are ambiguous, write the ambiguity into the list as a question and pick a defensible default, labeled as a guess.

Step 2: Red

Pick ONE item from the list - the simplest one that teaches you something. Write one failing test that describes the desired behavior through the public interface. Run it and watch it fail with the failure you expected. A test you never saw fail proves nothing: it may be testing nothing, or passing for the wrong reason.

Step 3: Green

Write the minimum code to pass - ugly, hardcoded, whatever. Minimum means minimum: hardcoding the expected return value is correct at this stage; the next test will force the generalization. Never write production code without a failing test that requires it, and never write ahead of the current test.

Step 4: Refactor

Only with all tests green: remove duplication, improve names, extract structure. Do not add behavior - behavior changes require going back to Red. Run the tests after every refactoring move.