1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
|
# 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.
|
