Test-Driven Development

Work in small red → green → refactor cycles: write one behavior as a test, watch it fail, implement it, then tidy the changed code. Read the project's glossary and relevant ADRs if they exist, whatever their filenames, so tests use the project's domain terms.

Decide whether a test is warranted

Write a test only when the change adds or alters a rule that users or callers will rely on from now on. Tests exist to catch realistic regressions of such rules; coverage by itself is not a reason to write one. If the change does not create such a rule, say so in one line and implement without the cycle.

Tests describe what the system does. Do not write a test that asserts a feature, route, option, or default is absent. A promised rejection or default is a behavior, so test the outcome itself: the endpoint returns 401 without credentials, or the destructive flag starts off. When removing behavior, delete the tests that covered it, find the callers that remain, and run the remaining suite; it covers only what it already tested, so check the remaining callers directly.

Do not write tests while drafting designs, UI, or ideas. Write them once the behavior is agreed and you are building it.

Choose the test

Before writing a test, name the requirement that sets the expected outcome, the starting conditions, and the realistic failure the test should catch.