Test with confidence, code with clarity

Your home for mastering Test-Driven Development through real-world katas and expert guidance.

TDD Buddy Logo
Latest Lights Out · Part 1 / 3 Lights Out, Part 1: The Flat Loop

Kata Catalog

Practice TDD with a curated set of real-world katas, each with clear requirements and test cases.

Browse Katas

Guides & References

Learn best practices, naming conventions, and advanced TDD techniques from industry experts.

Explore Guides

Interactive Learning

Discover the TDD Gears model and learn how to apply TDD principles in real-world scenarios.

Learn More

Why TDD Matters More in the AI Era

The bar for "good tests" just moved. Agents made it non-optional.

  • The last human gate was a bottleneck cosplaying as a safeguard. Proposal PRs stacked for weeks and merge-conflicted with each other while the human at the gate rubber-stamped or ignored them. The safeguard function had ended long before the block was removed.
  • A gate that does not read is not a gate. An approval that does not inspect what it approves is a queue token. Naming it review changes nothing about what it filters, which is nothing.
  • Machine-checkable guardrails are load-bearing review moved downstream. The allowlist on what a bot PR may touch, the schema validation that fails closed, the atomic push that either lands the whole change or none of it. Each is a check the human gate was supposed to perform and did not.
  • The trust surface is the guardrail, not the gatekeeper. An unattended pipeline earns trust the way a suite earns it: through the invariants the machinery refuses to violate, not through the presence of a reviewer who might notice.

Read the argument: Lights Out, Part 1: The Flat Loop

The Bar Moved

Old bar

Tests exist and pass. Good enough for humans with context.

New bar

Scenario names · builders · domain types · ubiquitous language. The test suite is the interface agents operate against.

TDD Gears

Shift gears based on context, not habit

TDD Gears model showing Low, Medium, High, and Reverse gears for test-driven development

Low Gear

New territory. Build context. Small steps. Learn the shape of the problem before solving it.

Medium Gear

Patterns emerge. Apply design principles. Let the tests guide you toward better abstractions.

High Gear

Known patterns. Follow existing architecture. Move fast because the structure is already proven.

Reverse Gear

Wrong direction. Back up. Delete the test. Try a different approach. This isn't failure — it's steering.