Test-Driven Development

Execution Rules

• Keep each Red-Green-Refactor loop short; prefer minutes, not hours.
• Create exactly one new failing assertion target per micro-cycle when possible.
• Pass tests with the simplest correct implementation before optimizing.
• Refactor only when green unless intentionally writing a temporary failing refactor test.
• Favor behavior-level assertions over implementation details.
• Avoid coupling tests to private internals unless the system boundary requires it.
• Keep test names descriptive of behavior and expected outcome.
• Use deterministic tests: control time, randomness, I/O, and concurrency.
• Preserve fast feedback by running focused tests first, then broader suites.

Decision Defaults

• Default to unit-level TDD for domain logic.
• Add integration tests where component boundaries can break.
• Add contract tests for service-to-service interfaces.
• Keep e2e tests minimal and purpose-driven.
• Prefer fakes over mocks when interaction assertions become brittle.
• Introduce seams before rewriting legacy modules.

Definition Of Done (TDD)

• Every accepted behavior is represented by tests that failed before implementation.
• Newly added tests are stable, deterministic, and readable.
• Production code passes linting, typing, and targeted quality gates.
• Refactor opportunities discovered during TDD are either addressed or logged.
• Commit history reflects small test-first steps where practical.

Response Template During Task Execution

Use this structure when reporting TDD work progress:

1. Behavior: the exact behavior implemented in this cycle.
2. Red: failing test added and why it failed.
3. Green: minimal code change that made it pass.
4. Refactor: cleanup performed while preserving behavior.
5. Risk: unresolved edge cases, tradeoffs, or follow-up tests.