atdd

Name: atdd
Author: dan-the-dev

27stars0forks

How to install atdd?

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

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

Installs into the current project.

Summary

Pragmatic Acceptance Test-Driven Development — agree concrete examples with stakeholders (Discuss), capture them as executable acceptance checks (Distill), then implement with outside-in delivery (Develop). Supports Gherkin/Cucumber when it helps, code-first acceptance tests, and

Files · 1

View on GitHub

SKILL.md

1	# Pragmatic ATDD (outside-in)
2
3	## Mission
4
5	Turn business intent into concrete, automated examples before (or as) the team builds the feature — so programmers and stakeholders mean the same thing when they say “done.”
6
7	First step of every capability slice: agree examples (scenarios, tables, or outcomes) and record them in a tracked artifact in the repo (path rules in [references/example-catalog.md](references/example-catalog.md)).
8
9	Distill step: turn the highest-value examples into at least one failing automated acceptance check at the right layer (see [references/environments-and-test-pyramid.md](references/environments-and-test-pyramid.md)) — unless the slice is explicitly example-only (UI mock) with a written deferral. For feasibility unknowns, use `skills/spike` on a `spike/` branch first, then return here after promotion.
10
11	Develop step: make acceptance green using outside-in work; use strict TDD (`skills/tdd`) for inner-loop programmer tests.
12
13	Optimize for:
14
15	- shared understanding (examples beat abstract requirements)
16	- executable definition of done (automated where practical)
17	- right layer (contract or narrow acceptance over slow full-stack when that still proves the business outcome)
18	- living documentation readable by non-programmers when possible
19	- composition with inner TDD — not duplication at every layer
20
21	This skill covers the outer acceptance loop. It does not replace unit TDD, bugfix workflows, CI pipeline design, or product discovery — compose with other skills for those.
22
23	---
24
25	## Discuss → Distill → Develop (pragmatic)
26
27	### 1. Discuss — agree examples
28
29	Who: business representative, developer, and someone who thinks about quality (the “triad” / three amigos) — roles can be played by the same person on small teams.
30
31	Test strategy: Before Distill, evaluate layers and specialized techniques per [`test-strategy-selection.md`](../../docs/test-strategy-selection.md) and [checklists/pipeline-fit.md](checklists/pipeline-fit.md) — contract vs API vs E2E; property-based or mutation only when they add evidence unit/acceptance cannot.
32
33	Output: concrete examples with agreed data, terminology, and boundaries — not a long specification document.
34
35	Practices:
36
37	- Start from a user story or capability and ask: “How would we manually check this is right?”
38	- Capture happy path, important edges, and failure the business cares about now.
39	- Use tables or Given / When / Then language when it helps clarity; plain bullet examples are fine.
40	- Record outcomes in the example catalog file before coding (see reference).
41
42	See [references/collaboration-and-examples.md](references/collaboration-and-examples.md).
43
44	### 2. Distill — automate the agreement
45
46	Transform agreed examples into executable checks:
47
48	\| Approach \| When (pragmatic) \|
49	\|----------\|------------------\|
50	\| Gherkin + runner (Cucumber, SpecFlow, pytest-bdd, etc.) \| Stakeholders will read scenarios in PRs; team already uses BDD tooling \|
51	\| Code-first acceptance (Playwright, API tests, RSpec feature specs) \| Faster for the team; examples stay in catalog + test names/assertions \|
52	\| Contract tests (Pact, schema/contract suites, consumer-driven contracts) \| Service boundary is the capability; business outcome is “honors agreed contract” \|
53	\| Narrow acceptance (HTTP against app, in-process acceptance module) \| Full E2E is slow/flaky but business rule can be proven at a stable seam \|
54
55	Rules:
56
57	- Prefer one failing acceptance check that proves the next agreed example — not a suite of ten scenarios upfront.
58	- The check must fail for the right reason (missing behavior), not environment noise — see [references/quality-and-flake-control.md](references/quality-and-flake-control.md).
59	- Do not block Distill on perfect Gherkin if code-first is the repo norm — keep the catalog as the human-readable source of truth.
60
61	See [references/discuss-distill-develop.md](references/discuss-distill-develop.md) and [references/gherkin-and-bdd-tooling.md](references/gherkin-and-bdd-tooling.md).
62
63	### 3. Develop — outside-in, then inner TDD
64
65	1. Acceptance RED: failing automated check for the current example.
66	2. Inner loop: use `skills/tdd` — test list + R–G–R — to grow production code until acceptance can

People who liked this also viewed

6 picks

Type

atdd

27stars0forks

View on GitHub

How to install atdd?

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

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

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Pragmatic ATDD (outside-in)
2
3	## Mission
4
5	Turn business intent into concrete, automated examples before (or as) the team builds the feature — so programmers and stakeholders mean the same thing when they say “done.”
6
7	First step of every capability slice: agree examples (scenarios, tables, or outcomes) and record them in a tracked artifact in the repo (path rules in [references/example-catalog.md](references/example-catalog.md)).
8
9	Distill step: turn the highest-value examples into at least one failing automated acceptance check at the right layer (see [references/environments-and-test-pyramid.md](references/environments-and-test-pyramid.md)) — unless the slice is explicitly example-only (UI mock) with a written deferral. For feasibility unknowns, use `skills/spike` on a `spike/` branch first, then return here after promotion.
10
11	Develop step: make acceptance green using outside-in work; use strict TDD (`skills/tdd`) for inner-loop programmer tests.
12
13	Optimize for:
14
15	- shared understanding (examples beat abstract requirements)
16	- executable definition of done (automated where practical)
17	- right layer (contract or narrow acceptance over slow full-stack when that still proves the business outcome)
18	- living documentation readable by non-programmers when possible
19	- composition with inner TDD — not duplication at every layer
20
21	This skill covers the outer acceptance loop. It does not replace unit TDD, bugfix workflows, CI pipeline design, or product discovery — compose with other skills for those.
22
23	---
24
25	## Discuss → Distill → Develop (pragmatic)
26
27	### 1. Discuss — agree examples
28
29	Who: business representative, developer, and someone who thinks about quality (the “triad” / three amigos) — roles can be played by the same person on small teams.
30
31	Test strategy: Before Distill, evaluate layers and specialized techniques per [`test-strategy-selection.md`](../../docs/test-strategy-selection.md) and [checklists/pipeline-fit.md](checklists/pipeline-fit.md) — contract vs API vs E2E; property-based or mutation only when they add evidence unit/acceptance cannot.
32
33	Output: concrete examples with agreed data, terminology, and boundaries — not a long specification document.
34
35	Practices:
36
37	- Start from a user story or capability and ask: “How would we manually check this is right?”
38	- Capture happy path, important edges, and failure the business cares about now.
39	- Use tables or Given / When / Then language when it helps clarity; plain bullet examples are fine.
40	- Record outcomes in the example catalog file before coding (see reference).
41
42	See [references/collaboration-and-examples.md](references/collaboration-and-examples.md).
43
44	### 2. Distill — automate the agreement
45
46	Transform agreed examples into executable checks:
47
48	\| Approach \| When (pragmatic) \|
49	\|----------\|------------------\|
50	\| Gherkin + runner (Cucumber, SpecFlow, pytest-bdd, etc.) \| Stakeholders will read scenarios in PRs; team already uses BDD tooling \|
51	\| Code-first acceptance (Playwright, API tests, RSpec feature specs) \| Faster for the team; examples stay in catalog + test names/assertions \|
52	\| Contract tests (Pact, schema/contract suites, consumer-driven contracts) \| Service boundary is the capability; business outcome is “honors agreed contract” \|
53	\| Narrow acceptance (HTTP against app, in-process acceptance module) \| Full E2E is slow/flaky but business rule can be proven at a stable seam \|
54
55	Rules:
56
57	- Prefer one failing acceptance check that proves the next agreed example — not a suite of ten scenarios upfront.
58	- The check must fail for the right reason (missing behavior), not environment noise — see [references/quality-and-flake-control.md](references/quality-and-flake-control.md).
59	- Do not block Distill on perfect Gherkin if code-first is the repo norm — keep the catalog as the human-readable source of truth.
60
61	See [references/discuss-distill-develop.md](references/discuss-distill-develop.md) and [references/gherkin-and-bdd-tooling.md](references/gherkin-and-bdd-tooling.md).
62
63	### 3. Develop — outside-in, then inner TDD
64
65	1. Acceptance RED: failing automated check for the current example.
66	2. Inner loop: use `skills/tdd` — test list + R–G–R — to grow production code until acceptance can

People who liked this also viewed

6 picks

Type