# Test Seams

> The reference that makes a red-green loop produce tests worth keeping, what a good test is, confirming the seams under test before writing any, and the three anti-patterns that make tests break on refactors or pass by construction. Use when writing or reviewing tests, doing red-green-refactor, or deciding what to test. Complements the loop itself (superpowers:test-driven-development drives red-green); this is the quality gate on what it produces.

- Skill: `presidenteog/test-seams` (Agent Skill)
- Install (CLI): `npx skillmds@latest add presidenteog/test-seams`
- Raw SKILL.md: https://api.skillmd.com/api/skills/presidenteog/test-seams/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: PresidenteOG (https://skillmd.com/u/presidenteog)
- Updated: 2026-09-22
- Page: https://skillmd.com/skills/presidenteog/test-seams

---


# Test Seams

Adapted from https://github.com/mattpocock/skills (mattpocock/skills, MIT) — rewritten, not copied.

## What a good test is
Verifies behaviour through a public interface, not implementation detail. Reads like a spec: "user can checkout with valid cart" tells you what capability exists and survives a refactor because it does not care about internal structure. Expected values come from an independent source of truth (a known-good literal, a worked example, the spec), never recomputed the way the code computes them.

## Confirm seams before writing tests
A **seam** is the public boundary you test at (see `deep-modules`). Before writing any test, write down the seams under test and confirm them with the user. No test at an unconfirmed seam. You cannot test everything; agreeing the seams up front is how effort lands on critical paths and complex logic instead of every edge case. Ask: "What is the public interface, and which seams should we test?"

## The three anti-patterns
| Name | Tell | Fix |
|---|---|---|
| Implementation-coupled | Mocks internal collaborators, tests private methods, asserts via a side channel (queries the DB instead of the interface). Breaks on refactor when behaviour has not changed | Test at the seam, through the interface only |
| Tautological | Assertion recomputes the expected value the way the code does (`expect(add(a,b)).toBe(a+b)`, a hand-derived snapshot, a constant equal to itself). Passes by construction, can never disagree with the code | Expected value from an independent source |
| Horizontal slicing | All tests first, then all implementation. Tests verify imagined behaviour and its shape, go insensitive to real change, lock in test structure before the implementation is understood | Vertical slices: one test, one minimal implementation, repeat; each test a tracer bullet |

## Loop rules
- **Red before green.** Failing test first, then only enough code to pass it. No speculative features.
- **One slice at a time.** One seam, one test, one minimal implementation per cycle.
- **Refactoring is not in the loop.** It belongs to review (`code-review`, `cavecrew-reviewer`), after green.