# Testing Standards

Applies to: `**/*`

Core TDD discipline and test quality rules. Language-specific patterns
(frameworks, fixture idioms, mocking tools) live in per-language testing files
under `languages/<lang>/claude/rules/`.

## Test-Driven Development (Default)

TDD is the default workflow for all code, including demos and prototypes. **Write tests first, before any implementation code.** Tests are how you prove you understand the problem — if you can't write a failing test, you don't yet understand what needs to change.

1. **Red**: Write a failing test that defines the desired behavior
2. **Green**: Write the minimal code to make the test pass
3. **Refactor**: Clean up while keeping tests green

Do not skip TDD for demo code. Demos build muscle memory — the habit carries into production.


## Test Categories — required for all code

Every unit under test needs all three, not just the happy path:

1. **Normal** — standard inputs, common workflows, typical volumes.
2. **Boundary** — zero, one, max, empty vs null, single-element collections, unicode, very long input, timezone and date edges.
3. **Error** — invalid input, type mismatches, network failure, missing parameters, permission denied, resource exhaustion, malformed data.

The negative and boundary cases are the ones that find bugs. A unit with only
Normal coverage is not tested, it is demonstrated.

## The rest of the standard lives in the `testing-standards` skill

Characterization tests for untested code, the per-category detail, combinatorial
and property-based and mutation testing, organization and the pyramid,
integration-test rules, naming, the test-quality rules (independence,
determinism, mocking boundaries, signs of overmocking), the
refactor-when-tests-are-hard principle, coverage targets, the spike exception,
and the anti-pattern list are all in the `testing-standards` skill. Load it when
writing tests.

What stays here is what has to be true before any code is written, which is when
no skill has been summoned yet: test first, and cover all three categories.

## Content scope

Test code, fixtures, docstrings, and comments are checked into the repo and visible to the team. They must follow the *Content scope for public artifacts* rule in [`commits.md`](commits.md): no local paths, no private repo names, no personal tooling references.