# Testing

> The how of testing: pyramid, AAA, isolation, risk coverage, determinism. Guarantees the DoD's "tests are green". test-expert-csk applies it. Use when writing or changing tests, or when a suite is flaky, slow or green for the wrong reason.

- Skill: `byerlikaya/testing` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add byerlikaya/testing`
- Raw SKILL.md: https://api.skillmd.com/api/skills/byerlikaya/testing/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: byerlikaya (https://skillmd.com/u/byerlikaya)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/byerlikaya/testing

---


# Testing Discipline

<!-- routing-eval reads this line; it lives in the BODY so the always-on skill LISTING stays inside
     Claude Code's budget (1% of the context window) — an overflowing listing gets descriptions
     truncated or dropped, which strips the very keywords a match depends on. -->
Trigger phrases: "write a test", "run the tests", "coverage", "are the tests green", "unit test", "integration test", "tests pass locally", "flaky test", "test is flaky"

Goal: **behavior correctness** — test real behavior without breaking product code just to make a test pass.

## Principles
- **Pyramid:** many unit, fewer integration, few end-to-end (e2e). Limit e2e to critical flows.
- **AAA:** Arrange-Act-Assert; **one test = one behavior**.
- **Isolation & determinism:** external dependencies are mocked/faked; time and randomness are fixed; test order is independent.
- **Risk-coverage:** risk, not metrics. Critical path + **boundary** + **negative** + **authorization (IDOR/404)** scenarios.
- **Naming:** `what_it_tests_under_which_condition_what_it_expects` — on failure it is clear what broke.
- **Red-green:** first a failing test, then the implementation.

## Watch out
- **Flaky = bug:** an occasionally failing test is not tolerated; it is fixed at the root.
- In snapshot/golden-file tests, avoid needless brittleness (assert only the meaningful output).

## Tests that cannot fail

Green is evidence only if the test could have gone red. Shapes that check nothing:
- **Assertion restates the code:** it recomputes the implementation's own expression, so it moves with every change.
- **Setup guarantees the result:** arrange plants the value the assert reads back; it holds even if the act never ran.
- **Expected value derived the way the code derives it:** same formula, query or parser — the same wrong assumption on
  both sides still matches.
- **A double asserted against its own stub:** the fake is told to return X and the test asserts X; only the fake runs.
- **No assertion:** it passes because nothing threw. If *not throwing* is the behavior under test, assert that.

**Prove it can fail:** break what the test covers — invert a condition, return a wrong constant — confirm it goes red,
then restore. Still green means the test is documentation, not a gate: fix it or delete it, never count it as coverage.

## Flaky triage
An intermittent failure gets exactly one outcome, decided the day it is seen: **fix** it, **quarantine** it (out of
the gating lane, never out of the suite, with an owner and a date), or **escalate** it as the product defect it
signals. Infrastructure flakes may get a bounded, logged retry; product flakes never do. Classifying them, the retry
rule, and what a quarantine entry must carry: **`references/flaky-triage.md`**.

## DoD (this skill's contribution)
- The project's own test command is green — read it off the manifest/CI (`dotnet test` · `npm test` · `pytest` ·
  `go test ./...`), don't assume one; critical paths are covered; no empty/meaningless tests.