Test-Driven Development

Test-driven development, or TDD, is programming arranged around evidence instead of hopeful nodding at a diff. You write one small automated test for behavior that does not exist yet, watch it fail for the right reason, make it pass, then improve the structure while the tests guard the exits. The loop has the memorable traffic-light names red, green, refactor, because software people are apparently comforted by colors.

The important bit is not that tests appear before code in a ceremonial queue. Red proves that the new test can notice the missing behavior. A failure caused by an import, a typo, or a broken fixture is merely a different sort of red flag. Green restores a working baseline after a focused code change. Refactor changes internal structure while the observed behavior stays put. Each step answers a different question, which is far more useful than treating one large passing suite as a decorative houseplant.

A test list keeps the next decision small. Start with a normal case that establishes the public interface. Add another example when the first one passes too cheaply. Then use boundary and error cases to expose rules nobody had to decide earlier. The list can change as the code teaches you something, which is precisely why writing twenty tests before running one is less heroic than it sounds.

Tests also reveal design trouble. Awkward setup, hidden global state, and a crowd of collaborators are not merely irritating obstacles between you and a green check mark. They can show that the production boundary is carrying too much coupling. Prefer an assertion about a returned value, durable state, or required message over an assertion that a private helper performed its little dance in the approved sequence.

A test double is useful when a real collaborator is slow, unstable, or difficult to provoke. It makes one boundary controllable, but it cannot prove that the real service behaves the same way. That is why TDD lives beside integration checks, exploratory work, security analysis, performance testing, and operational validation. No single test suite is a wizard, even when it owns a very confident runner.

Continue with the intro for the full map of the cycle and its limits. Use the slides when you want the relationships at a glance, the cheatsheet when a red result needs diagnosis, and the practice exercise when this stops being a sensible theory and starts producing evidence in a local program.

Test-Driven Development

Relevant careers