adrien-barret/tdd-enforced

TDD Protocol — Non-Negotiable

Rule: NO production code without a failing test FIRST. Code written before a test exists must be deleted and restarted. No exceptions for code stories.

The Cycle

For each behavior to implement:

1. RED — Write ONE minimal test for ONE specific behavior

   • The test MUST fail when you run it
   • It must fail for the RIGHT reason (missing feature, not a typo or import error)
   • Run the test. Confirm it fails. Screenshot or paste the failure output.

2. GREEN — Write the MINIMUM code to make the test pass

   • Do not write more code than the test demands
   • Do not add "while I'm here" improvements
   • Run the test. Confirm it passes. All previous tests still pass.

3. REFACTOR — Clean up ONLY after green

   • Remove duplication, improve naming, simplify
   • Run tests after every refactoring step
   • If a test breaks during refactor, undo and try again

4. REPEAT — Next behavior, next failing test

Verification at Every Step

You MUST run the test suite after each step:

• After RED: confirm the new test fails (and only the new test)
• After GREEN: confirm all tests pass
• After REFACTOR: confirm all tests still pass

If you skip verification, the cycle is broken. Start over.

Anti-Rationalization Table

| Excuse | Response | |--------|----------| | "This is too simple to test" | Simple code breaks. The test takes 30 seconds to write. | | "I'll add the test after" | Tests written after code prove nothing — they're designed to pass. | | "TDD will slow me down" | TDD is faster than debugging. The test IS the specification. | | "I just need to try something first" | Try it IN a test. Write the test as an experiment. | | "The framework handles this" | Frameworks have bugs. Test YOUR usage of the framework. | | "It's just a config change" | Config changes break things. If it can break, test it. | | "I know this works" | Prove it. Write the test. | | "The test is obvious" | Then it takes 10 seconds to write. Do it. | | "I need to see the structure first" | The test IS the structure. Let the test drive the design. | | "This is just refactoring" | Refactoring requires green tests BEFORE you start changing code. | | "It's a one-liner" | One-liners have the highest bug-per-line ratio. Test it. | | "I'll test the integration instead" | Integration tests are slow and coarse. Unit test first, integrate second. |

Red Flags — Start Over If You See These

• You wrote production code before writing a failing test → DELETE the code, write the test first
• Your new test passes immediately without writing new code → The test is wrong or the feature already exists. Investigate.
• You wrote multiple tests at once → Write ONE test at a time
• You're writing tests "for coverage" after implementation → These are not TDD tests. Delete and redo with RED first.
• You haven't run the tests in more than 5 minutes → Run them NOW

Exceptions

TDD is optional for these story types (classified in the implementation plan):

• Config files: YAML, JSON, TOML, environment variables
• Infrastructure: Terraform, Helm charts, Dockerfiles, CI/CD pipelines
• Database migrations: Schema changes, seed data
• Static assets: CSS, images, documentation-only changes
• Markdown templates: Skill files, agent definitions, prompt templates

For everything else: RED-GREEN-REFACTOR, no exceptions.