How to Practice TDD: A Repeatable Routine for Developers
TDD is not learned by watching. It is learned in tight red-green-refactor loops. This guide shows how to practice with katas, constraints, and cycle-time feedback.
Why TDD practice stalls
Most developers try to learn test-driven development inside a real feature. The feedback loop is too long, the domain is noisy, and the pressure to ship overrides the discipline. Practice needs a small, low-stakes environment where the only goal is the loop.
Start with katas, not projects
A kata is a small coding exercise you repeat. Good starting points:
FizzBuzz: simple rules, quick feedback.
String Calculator: incremental parsing rules.
Bowling Game: state and scoring logic.
Gilded Rose: refactoring and characterization tests.
Kent Beck demonstrates TDD from scratch in *Test-Driven Development: By Example*. The original examples still work because they are small enough to force the red-green-refactor sequence.
Run the red-green-refactor loop mechanically
Red
Write exactly one failing test. Run it. Confirm the failure message matches your expectation. If the test fails for the wrong reason, fix the test before adding production code.
Green
Write the smallest amount of production code that makes the test pass. Do not add abstractions, utilities, or future-proofing. The goal is feedback speed, not code elegance yet.
Refactor
Clean up duplication, naming, and structure while the tests are green. Run the tests after every small change. If you cannot refactor safely, the test is too large or the code is too tangled.
Add constraints to expose weak spots
Constraints make practice deliberate.
No production code without a failing test.
One assertion per test until the habit is automatic.
Maximum five minute cycle time for a simple kata.
Use only test-first; if you catch yourself writing code first, revert and start again.
Robert Martin's Transformation Priority Premise is useful here. It orders the tiny transformations that should appear as tests pass. It keeps you from jumping to an implementation that skips behavior.
Measure cycle time
Track the time from red to green for each test. In a focused kata session, cycles should settle between two and five minutes. Longer cycles usually mean the test covers too much behavior. Split it.
Practice with another developer
Pairing exposes silent assumptions. One person writes the test, the other writes the production code. Switch after each cycle. This is especially useful for learning how small a test should be.
Build a personal kata repository
Keep a folder with your favorite katas, test commands, and notes. Revisit the same kata weekly with different constraints or languages. The point is not to memorize solutions. It is to make the feedback loop automatic.
Move from katas to real code carefully
When the loop feels natural, take a real bug or small feature and reproduce the behavior with a failing test first. Do not begin with a large legacy codebase. Small slices preserve the practice.
At Sapior, we apply this same loop to our own developer tools and automation. A fast test command, a clean sandbox, and a short feedback loop make TDD a habit instead of a ceremony.