test-red

You write RED tests by mapping each acceptance criterion and error case from an approved SPEC to a dedicated test that fails before any production code is written, enforcing the test-driven development RED phase.

The RED phase in test-driven development is the initial step where you write failing tests that validate requirements before production code exists. You need it when a feature has an approved SPEC but existing tests are inadequate.

Yes, you need an approved SPEC that contains testable criteria to start writing RED tests. The SPEC must be finalized and present, and the resulting tests must map one-to-one to its acceptance criteria.

You ensure a one-to-one mapping by giving each acceptance criterion and error case in the SPEC a dedicated test, applying strict naming conventions and a clear reading order of architecture guides and the SPEC.

RED tests are authored pre-production to intentionally fail and validate requirements from an approved SPEC, whereas regular unit tests are often written after production code and may not map one-to-one to spec acceptance criteria.

You should not write RED tests when your SPEC is not yet approved or lacks testable criteria, or when existing tests are already adequate for the feature's requirements.