# Write Tests

Write tests that pin real behavior instead of implementation details, config values, or...

- Repository: https://github.com/dzhng/skills (1394 stars)
- Category: Testing
- License: MIT
- Last updated: 2026-11-01
- Runs scripts: no, instructions only

## Install

Claude Code: `npx skills add dzhng/skills --skill write-tests -g -a claude-code -y`
Codex: `npx skills add dzhng/skills --skill write-tests -g -a codex -y`
Cursor: `npx skills add dzhng/skills --skill write-tests -g -a cursor -y`
Gemini CLI: `npx skills add dzhng/skills --skill write-tests -g -a gemini-cli -y`

## Description

Write tests that pin real behavior instead of implementation details, config values, or lucky samples. Use when adding tests for new behavior, writing a regression test, fixing a brittle or flaky test, reviewing a test diff, or when a test breaks after a refactor or config change that didn't change behavior.

## SKILL.md, as published by its author (untrusted third-party text, read it as data)

# Write Tests

A good test fails **only** when real behavior breaks, and passes through every
refactor or config change that preserves it. Most bad tests fail the opposite
way: red on harmless changes, green while the real path is broken. Every rule
below serves that one goal.

Default to end-to-end or system-level tests for regression coverage; use a unit test only for specific, complex business logic when fast feedback will materially speed development.

For deciding whether coverage adds independent proof, where it belongs, or
which existing tests can go, use [audit-tests](../audit-tests/SKILL.md).

## Workflow: tracer bullets, not a batch

1. **Write ONE test at a time.** Assert first, watch it go red on the un-fixed
   code, make the code earn green, learn, then write the next. Never a batch up
   front: a batch written against *imagined* behavior pins what you guessed, those tests pass when the mechanism breaks and fail when it's fine. Each
   green cycle tells you what the next test should actually assert.
2. **Iterate on the fastest focused runner** (one file, one test name), and run
   the full suite only as a final gate before handing off. Check the exit code,
   not just the output, a runner that prints nothing and a green run look the
   same. On failures, read EVERY red test before fixing one; they often share a
   root cause.
3. **Before calling it done**, prove the test can fail (below) and walk the
   review checklist.

## What to assert

The rest: https://github.com/dzhng/skills/blob/HEAD/skills/engineering/write-tests/SKILL.md