tdd

Files (4)

• SKILL.md
• openai.yaml · agents/
• mocking.md
• tests.md

SKILL.md (first lines)

# Test-Driven Development

Use red → green → refactor for behavioral changes where an independent assertion can catch a regression. Match effort to the change; documentation, formatting, and reversible low-impact edits usually need existing checks rather than new tests.

When exploring the codebase, read `GLOSSARY.md` (if it exists) so test names and interface vocabulary match the project's domain language, and respect ADRs in the area you're touching.

## What a good test is

Tests verify behavior through public interfaces, not implementation details. Code can change entirely; tests shouldn't. A good test reads like a specification: "user can checkout with valid cart" tells you exactly what capability exists, and it survives refactors because it doesn't care about internal structure.

See [tests.md](tests.md) for examples and [mocking.md](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.

Reuse boundaries established in the task, spec, and existing suite. Otherwise select the smallest public boundary that catches the requested behavior, state what it catches and misses, and proceed within the authorized task. Ask only when the choice changes product behavior, scope, or a material architectural trade-off.

Preserve explicitly requested approval gates. Existing authorization persists; routine regression tests at an existing boundary do not need another confirmation.

When the shape of that interface is itself in question (how deep the module is, where the seam belongs, what the interface should expose), load the installed `codebase-design` skill with the available skill tool or by reading its `SKILL.md` for the vocabulary. It is the shared source of the module, interface, depth, seam, adapter, leverage and locality terms, and it is a reference to consult, not a session to run.

## Anti-patterns

- **Implementation-coupled**: mocks internal collaborators, tests private methods, or verifies through a side channel (querying the database instead of using the interface). The tell: the test breaks when you refactor but behavior hasn't changed.
- **Tautological**: the assertion recomputes the expected value the way the code does (`expect(add(a, b)).toBe(a + b)`, a snapshot derived by hand the same way, a constant asserted equal to itself), so it passes by construction and can never disagree with the code. Expected values must come from an independent source of truth: a known-good literal, a worked example, the spec.
- **Horizontal slicing**: writing all tests first, then all implementation. Bulk tests verify _imagined_ behavior: you test the _shape_ of things rather than user-facing behavior, the tests go insensitive to real changes, and you commit to test structure before understanding the implementation. Work in **vertical slices** instead: one test → one implementation → repeat, each test a **tracer bullet** that responds to what the last cycle taught you.

## Check each test before keeping it

`review-tests` audits tests after they're written; hold each new test to the same bar now so there is nothing for it to find. Before keeping a test, answer its three questions:

1. **What real code runs?** The production entrypoint and the decision under test execute; only system boundaries are replaced (see [mocking.md](mocking.md)). A test that mocks the subject, reimplements it, or only imports it verifies nothing.
2. **What independently establishes correctness?** The expected value comes from the spec, a worked example, or a domain rule, never from the code's own helpers, the current output, or a value the fake supplied.
3. **What plausible regression would fail it?** Name one. Red-before-green shows this for new behavior. When adding a test for code that already works, temporarily break the relevant decision, watch the test fail on its assertion (not a setup or import error), and restore.

Also avoid the defects `review-tests` most often finds beyond the anti-patterns above:

- **Weak failure checks**: assert the specific error and that no forbidden side effect happened; pair each rejection with an accepted neighbouring case.
- **Nondeterminism**: no shared state, order dependence, wall clock, fixed ports, live network, or ambient environment; control time and randomness.
- **Timing coupling**: no sleeps to wait for ordering; wait on an event or condition with a bound, and surface worker exceptions to the test.
- **Over-precise assertions**: no source-string searches, giant snapshots, or exact serialization unless that format is the contract.

For judgment calls, such as when exact call counts, private fault injection, or real elapsed time are legitimate, read the installed `review-tests` skill's `references/review-cases.md`.

## Rules of the loop

- **Red before green.** Write the failing test first, then only enough code to pass it. Don't anticipate future tests or add speculative features.
- **One slice at a time.** One seam, one test, one minimal implementation per cycle.
- **Refactor while green.** Simplify the tested change without changing behavior, then rerun affected checks. Broader architectural work needs its own justification and scope.

From corynaegle-ai/agent-skills, MIT.

More from corynaegle-ai/agent-skills