Test with confidence, code with clarity

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

TDD Buddy Logo
Latest Harness Engineering Is the Test Suite, Renamed

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 naming arrived before the substance. A February practitioner post coined the term, an arxiv wave followed, benchmark tables added a harness column, and the observation underneath never had a season to catch up with the branding.
  • Every harness taxonomy rediscovers the same load-bearing layer. CI gates, test-suite feedback, deterministic verification loops, sandbox permissions that fail closed. Strip the rebranding and count how many of the top-tier layers are the maintained verification surface under a new label.
  • Memory, planning, and scratchpads change what the agent remembers, not what ships. The new parts are real and useful. They shape run-time behavior. They do not decide whether the code that landed is correct. That decision lives in the verification surface the harness wraps.
  • A rich harness around a weak suite is a scaffold around a rotten frame. The ceiling on an agent-generated PR is bounded by the discrimination power of the tests it must satisfy. The harness reaches the ceiling faster. It does not raise it.

Read the argument: Harness Engineering Is the Test Suite, Renamed

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.