akathecoder Test-Driven Development
TDD is the red-to-green loop. Tests verify behavior through public interfaces, not implementation details, and each cycle lands one narrow vertical slice.
Process
Read the active project's
CONTEXT.md, relevant ADRs, approved spec, and ticket before testing. Identify the highest existing public seam that demonstrates the required behavior. If a new seam is needed, propose it before writing tests.Done when the test seam is agreed and named in the implementation work.
Write one failing behavior test at that seam. Use an independent expected value and avoid internal mocks, private methods, call-order assertions, and database side-channel verification.
Done when the test fails for the missing behavior.
Write only the implementation needed to make that test pass. Run the focused test and typecheck regularly.
Done when the focused test passes without speculative behavior.
Repeat one vertical slice at a time. Mock only system boundaries such as external APIs, time, randomness, and sometimes file systems or databases. Prefer real test infrastructure where practical.
Done when all approved behavior at the seam is covered by behavior-focused tests.
Run the repository's coverage tooling for changed code. Target 100% coverage and require at least 95%, unless the user or repository explicitly opts out. Improve meaningful missing coverage rather than adding tautological tests.
Done when coverage meets the agreed threshold or the explicit exception is recorded in the implementation artifact.