dhpk-tdd-workflow

Test-Driven Development

Test-generation mode

When invoked with test-generation, inspect the named production seam and its existing test conventions, then generate the smallest behavior-focused test scaffold. The caller must review and run the generated test before claiming a GREEN result. This is the canonical replacement for the retired /codex-test-gen command; use an explicitly selected Codex backend only when the caller requests one.

Use this skill to keep tests attached to observable behavior rather than implementation details. Read tests.md when writing or reviewing assertions and mocking.md before introducing a test double.

Before choosing names or seams, read CONTEXT.md when the repository provides one and respect nearby ADRs. Keep test vocabulary aligned with the project's domain language rather than inventing test-only names.

Standard TDD mode

Use this mode for tdd-guide and any task that owns test strategy:

1. Identify the public interface and the behavior that should be observable.
2. Confirm the seam from the user request, approved plan, or dispatcher brief.
3. Write one small test for that behavior and run it before implementation.
4. Confirm RED fails for the intended missing behavior, not a test/setup error.
5. Write only enough production code to make that test GREEN.
6. Run the scoped test again, then refactor only while it remains green.
7. Repeat one vertical slice at a time; run the applicable full suite at phase exit rather than broad speculative tests on every loop.

Tests must assert return values, emitted state, or caller-visible side effects. Do not test private methods, internal call counts, or a value through a side channel that bypasses the public interface. Expected values must come from a literal, worked example, or independent specification; never recompute them with the same logic as the implementation.

Seams and slicing rules

• Name the public seams before writing the test: API, command, event, or other caller-visible boundary. Keep tests at that seam unless a genuine external boundary requires a narrow adapter test.
• Use independent expected values from a literal example or specification; a test that calls the same helper to compute its expected result is tautological and cannot detect a shared defect.
• Build vertical tracer bullets: one failing behavior through the real boundary and minimal collaborators, then expand coverage around the same path.
• Keep the loop vertical: one test, one minimal implementation, then one refactor while green. Avoid writing a horizontal batch of imagined tests before the first behavior is understood.
• Avoid horizontal slicing (all models, then all services, then all controllers). It delays feedback and encourages implementation-coupled tests.
• Reject implementation-coupled assertions on private names, incidental call counts, or internal data shape. A tautological test is a test smell, not evidence of coverage.