Red, then green

A change in behaviour starts with a test that fails for the right reason, and ends when that test and the rest of the suite pass.

Reads: Test runner
When: Before the code for a new behaviour or a fix is written, and again after it.
Failure: The new test passes before the change, fails for a reason other than the missing behaviour, or any test fails after the change.
Next: The agent changes the code, never the new test, and runs the tests again. When the test cannot be made to fail for the right reason, or the same failure keeps coming back, it stops and shows a person the test.
Tools: Contract broker, Scripted model responses, The project's snapshot library, The project's test command, Throwaway dependencies

No illustration yet catalog/loops/red-green-tdd/card.svg

The loop

Write a test for the behaviour the change should add or fix.
Run it and watch it fail. Read the failure: the test must fail because the behaviour is missing (its assertion does not hold), not because of a typo, an import error or a broken fixture.
Make the smallest change to the code that makes the test pass.
Run the whole suite. The new test, and every test that passed before, must pass now.

Why red first

A test that has never failed has not been shown to detect anything. Seeing it fail for the right reason is what makes its later pass mean something.

Where it does not apply

Changes with no behaviour to state as a test: formatting, documentation, a rename done by a tool. There the loop has nothing to read, and another sensor (the type checker, the linter) does the checking.

Built from catalog/loops/red-green-tdd/card.md.