The Three Rules of TDD are simple:

  • Write no production code until you have a failing test.
  • Write only enough tests to fail.
  • Write only enough production code to pass.

When builders follow this discipline, their work is verifiable every minute.

Small, frequent checks catch errors early and keep risk manageable. TDD is the balance sheet that helps us avoid catastrophes.

Discussions for your team

  • Which high-risk parts of our software would benefit from requiring strict TDD?
  • In which areas of our software are we resisting writing tests first, and why?
  • What tooling would make TDD easier?