Test-Driven Development

TDD is the red → green loop. This skill is the reference that makes that loop produce tests worth keeping: what a good test is, where tests go, the anti-patterns, and the rules of the loop. Every section applies on every cycle: consult them before and during the loop, not after.

Resolve and read the configured vocabulary and relevant ADRs through /domain-modeling so test names and interfaces match the project's domain language.

Invoke /pstack-principles for the testing and implementation work in this slice before changing code. Recheck when a new design constraint or failure changes the applicable owners; continue the same red/green loop.

What a good test is

Invoke /pstack-principle-test-behavior-not-implementation for the authoritative test-quality criteria. This owner supplies the red/green mechanics and seam selection.

See tests.md for examples and mocking.md for mocking guidelines.

Seams: where tests go

A seam is the public boundary you test at: the interface where you observe behavior without reaching inside. Tests live at seams, never against internals.

Use agreed or established public seams. Reuse seams from the approved spec, existing callers, or the invoking workflow. State what each chosen seam observes and misses. Ask when a new interface or unresolved acceptance decision changes the approved contract; do not repeat an already-resolved approval. If a practical regression path is unavailable, preserve the executable evidence and disclose that gap rather than building a brittle test harness.