tdd

Name: tdd
Author: dan-the-dev

27stars0forks

How to install tdd?

dan-the-dev/xp-developer-skills/tdd

$npx -y skills add dan-the-dev/xp-developer-skills --skill tdd

Installs into the current project.

Summary

Applies strict Test-Driven Development with a repo-local Markdown test list (default test-lists/<slug>.md unless the project defines another folder), Robert C. Martin’s Three Laws, deterministic tests and stable seams (unit vs narrow integration), Arrange–Act–Assert test shape,

Files · 1

View on GitHub

SKILL.md

1	# Strict TDD (micro-iterations)
2
3	## Mission
4
5	Shared delivery rules at slice boundaries: [`docs/delivery-process.md`](../../docs/delivery-process.md) (§2 verification, §3 change-surface, §4 test strategy, §6 RED→GREEN), [`docs/project-verification.md`](../../docs/project-verification.md), and [`docs/test-strategy-selection.md`](../../docs/test-strategy-selection.md).
6
7	Turn requirements into concrete automated examples before production code exists: each example is a small failing test, then the smallest code that passes, then structure improvements without changing behavior.
8
9	First step of every feature: create a Markdown test list file in the repo (path rules in [references/test-list.md](references/test-list.md)) listing every behavior you will prove with tests; keep the file updated. Last step: every line in that file is done and the suite is green — then the slice is finished.
10
11	Implement using short RED → GREEN → REFACTOR cycles. Each cycle targets the smallest increment that still moves the design forward.
12
13	Optimize for:
14
15	- a tracked Markdown file for the test list (repo-visible “done” definition)
16	- strict adherence to the Three Laws of TDD
17	- one failing test at a time
18	- fastest possible feedback (narrowest test run)
19	- reversible steps
20	- commits that tell the story of the cycle
21	- tests that describe behavior, not internals
22	- deterministic tests and stable seams (see behavior reference)
23	- refactors scoped to code near the current change
24
25	This skill covers the inner unit-level TDD loop. Before first RED, evaluate other practices per [`test-strategy-selection.md`](../../docs/test-strategy-selection.md) (mutation, property-based, narrow integration). It does not specify acceptance-test (outer-loop) workflows, legacy code without tests, branching policy, CI, bugfix-only rules, or time-boxed experiments — compose with other skills for those (e.g. `skills/atdd`, `skills/spike` on an isolated `spike/` branch before delivery, `skills/refactoring` for stand-alone Fowler-style refactor sessions, `skills/legacy-testing` for Feathers-style harness and characterization).
26
27	---
28
29	## Test list (mandatory)
30
31	The test list lives in a tracked `.md` file in the project. It contains only behaviors that will become automated tests — not deferred refactors (those go to a follow-ups file or the closing reply; see [references/test-list.md](references/test-list.md)).
32
33	Before the first RED for a feature slice:
34
35	1. Choose folder: use a path the project already defines for this kind of artifact; if none, use `test-lists/` at the repo root.
36	2. Create the file with a name derived from the branch and/or feature (kebab-case, coherent slug — details in reference).
37	3. Write every behavior case you can already name (happy paths, edges, errors, invariants) as `[ ]` checklist lines.
38	4. During development: flip lines to `[x]` when a real automated test exists and passes for that case; append new `[ ]` lines for newly discovered behavior only.
39	5. The slice is complete when every behavior line is `[x]` (or explicitly removed by agreement) and tests are green.
40
41	Do not add refactor-only or “nice cleanup” items to this file — they would prevent a clear “feature done” signal.
42
43	See [references/test-list.md](references/test-list.md) for folder resolution, naming, and follow-ups.
44
45	---
46
47	## The Three Laws of TDD (strict)
48
49	These laws (commonly attributed to Robert C. Martin) define the rhythm. Do not skip or reinterpret them; they override convenience.
50
51	### Law 1 — Production code only for green
52
53	You may not write production code unless it is to make a failing unit test pass.
54
55	- No speculative types, helpers, or “we will need this” code without a current failing test that demands it.
56	- If there is no failing test, you do not touch production code.
57
58	### Law 2 — Minimal test to fail
59
60	You may not write more of a unit test than is sufficient to fail (including not compiling / not resolving symbols, where that is the next smallest step in your stack).
61
62	- Write only enough test to get one clear failure signal.
63	- A compile-time / type error from calling a not-yet-written API counts as RED.
64
65	### Law 3 — Minimal production to pass
66
67	You may

People who liked this also viewed

6 picks

Type

tdd

27stars0forks

View on GitHub

How to install tdd?

dan-the-dev/xp-developer-skills/tdd

$npx -y skills add dan-the-dev/xp-developer-skills --skill tdd

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Strict TDD (micro-iterations)
2
3	## Mission
4
5	Shared delivery rules at slice boundaries: [`docs/delivery-process.md`](../../docs/delivery-process.md) (§2 verification, §3 change-surface, §4 test strategy, §6 RED→GREEN), [`docs/project-verification.md`](../../docs/project-verification.md), and [`docs/test-strategy-selection.md`](../../docs/test-strategy-selection.md).
6
7	Turn requirements into concrete automated examples before production code exists: each example is a small failing test, then the smallest code that passes, then structure improvements without changing behavior.
8
9	First step of every feature: create a Markdown test list file in the repo (path rules in [references/test-list.md](references/test-list.md)) listing every behavior you will prove with tests; keep the file updated. Last step: every line in that file is done and the suite is green — then the slice is finished.
10
11	Implement using short RED → GREEN → REFACTOR cycles. Each cycle targets the smallest increment that still moves the design forward.
12
13	Optimize for:
14
15	- a tracked Markdown file for the test list (repo-visible “done” definition)
16	- strict adherence to the Three Laws of TDD
17	- one failing test at a time
18	- fastest possible feedback (narrowest test run)
19	- reversible steps
20	- commits that tell the story of the cycle
21	- tests that describe behavior, not internals
22	- deterministic tests and stable seams (see behavior reference)
23	- refactors scoped to code near the current change
24
25	This skill covers the inner unit-level TDD loop. Before first RED, evaluate other practices per [`test-strategy-selection.md`](../../docs/test-strategy-selection.md) (mutation, property-based, narrow integration). It does not specify acceptance-test (outer-loop) workflows, legacy code without tests, branching policy, CI, bugfix-only rules, or time-boxed experiments — compose with other skills for those (e.g. `skills/atdd`, `skills/spike` on an isolated `spike/` branch before delivery, `skills/refactoring` for stand-alone Fowler-style refactor sessions, `skills/legacy-testing` for Feathers-style harness and characterization).
26
27	---
28
29	## Test list (mandatory)
30
31	The test list lives in a tracked `.md` file in the project. It contains only behaviors that will become automated tests — not deferred refactors (those go to a follow-ups file or the closing reply; see [references/test-list.md](references/test-list.md)).
32
33	Before the first RED for a feature slice:
34
35	1. Choose folder: use a path the project already defines for this kind of artifact; if none, use `test-lists/` at the repo root.
36	2. Create the file with a name derived from the branch and/or feature (kebab-case, coherent slug — details in reference).
37	3. Write every behavior case you can already name (happy paths, edges, errors, invariants) as `[ ]` checklist lines.
38	4. During development: flip lines to `[x]` when a real automated test exists and passes for that case; append new `[ ]` lines for newly discovered behavior only.
39	5. The slice is complete when every behavior line is `[x]` (or explicitly removed by agreement) and tests are green.
40
41	Do not add refactor-only or “nice cleanup” items to this file — they would prevent a clear “feature done” signal.
42
43	See [references/test-list.md](references/test-list.md) for folder resolution, naming, and follow-ups.
44
45	---
46
47	## The Three Laws of TDD (strict)
48
49	These laws (commonly attributed to Robert C. Martin) define the rhythm. Do not skip or reinterpret them; they override convenience.
50
51	### Law 1 — Production code only for green
52
53	You may not write production code unless it is to make a failing unit test pass.
54
55	- No speculative types, helpers, or “we will need this” code without a current failing test that demands it.
56	- If there is no failing test, you do not touch production code.
57
58	### Law 2 — Minimal test to fail
59
60	You may not write more of a unit test than is sufficient to fail (including not compiling / not resolving symbols, where that is the next smallest step in your stack).
61
62	- Write only enough test to get one clear failure signal.
63	- A compile-time / type error from calling a not-yet-written API counts as RED.
64
65	### Law 3 — Minimal production to pass
66
67	You may

People who liked this also viewed

6 picks

Type