test-driven-development

Name: test-driven-development
Author: AlexAI-MCP

132stars24forks

How to install test-driven-development?

alexai-mcp/hermes-ccc/test-driven-development

$npx -y skills add AlexAI-MCP/hermes-CCC --skill test-driven-development

Installs into the current project.

Summary

Apply a disciplined red-green-refactor workflow in Claude Code. Use when adding behavior safely, reproducing a bug before fixing it, designing APIs from the outside in, or strengthening change confidence with targeted tests.

Files · 1

View on GitHub

SKILL.md

1	# Test-Driven Development
2
3	## Purpose
4
5	- Drive implementation from observable behavior.
6	- Reproduce bugs before fixing them.
7	- Keep code changes tightly coupled to expected outcomes.
8	- Use tests as design tools, not just safety nets.
9	- Reduce regressions by proving each behavior change.
10
11	## Activation Signals
12
13	- Use this skill when adding a new feature with clear acceptance behavior.
14	- Use this skill when fixing a bug that should never recur.
15	- Use this skill when API shape is easier to design from usage than internals.
16	- Use this skill when reviewers will ask for evidence.
17	- Use this skill when the codebase already has a strong test culture.
18
19	## Core Cycle
20
21	1. Write a failing test.
22	2. Run the smallest test scope and watch it fail for the right reason.
23	3. Implement the smallest change that makes it pass.
24	4. Re-run the test.
25	5. Refactor while keeping tests green.
26	6. Expand coverage only when a new behavior boundary appears.
27
28	## Red Phase
29
30	- Express one behavior at a time.
31	- Name the test after the behavior, not the implementation.
32	- Ensure the failure is caused by missing behavior, not a broken fixture.
33	- Keep setup minimal.
34	- Prefer explicit assertions over snapshot sprawl unless snapshots are already standard.
35	- For bug fixes, make the failing test mirror the actual defect.
36
37	## Green Phase
38
39	- Implement the smallest viable change.
40	- Do not optimize before the test passes.
41	- Avoid speculative abstractions.
42	- If several code paths fail, make one behavior pass first.
43	- Keep the first passing diff small enough to reason about.
44
45	## Refactor Phase
46
47	- Remove duplication exposed by the passing test.
48	- Improve names and structure.
49	- Preserve behavior while simplifying code.
50	- Re-run relevant tests after each meaningful refactor.
51	- Stop refactoring once readability improves and the tests still describe the behavior clearly.
52
53	## Bug-Fix TDD
54
55	- Reproduce the bug in a failing test before touching the fix.
56	- If reproduction is expensive, build a narrow harness.
57	- If the bug is timing-sensitive, isolate the timing dependency rather than sleeping more.
58	- If the bug cannot be reproduced, treat the fix as higher risk and document why.
59
60	## Test Selection Rules
61
62	- Use unit tests for pure behavior and deterministic branching.
63	- Use integration tests for component boundaries and data flow.
64	- Use end-to-end tests only when lower layers cannot express the guarantee.
65	- Put the regression test at the lowest layer that still captures the defect.
66
67	## Assertion Rules
68
69	- Assert the most important observable outcome first.
70	- Prefer stable assertions over implementation detail checks.
71	- Avoid asserting on incidental formatting unless formatting is the feature.
72	- For collections, assert the contract that matters: count, key values, order, or identity.
73
74	## Good Test Names
75
76	- `test_search_returns_ranked_results_for_partial_match`
77	- `test_login_redirect_does_not_loop_when_session_is_hydrated`
78	- `test_serializer_rejects_missing_required_field`
79
80	## Bad Test Names
81
82	- `test_fix`
83	- `test_works`
84	- `test_api`
85	- `test_stuff`
86
87	## Useful Commands
88
89	```bash
90	pytest tests/test_module.py::test_specific_behavior -vv
91	pytest tests/ -k "auth and redirect" -vv
92	ruff check path/to/file.py
93	```
94
95	## Design Benefits To Exploit
96
97	- Tests clarify API ergonomics.
98	- Tests reveal hidden dependencies.
99	- Tests pressure functions toward clean inputs and outputs.
100	- Tests expose when code is too coupled to mock cleanly.
101
102	## Decision Rules
103
104	- If a feature request has no acceptance behavior, clarify before writing code.
105	- If the first test is too hard to write, the design seam may be missing.
106	- If the code needed to pass the test is huge, the test scope is probably too broad.
107	- If refactoring requires changing many tests, the tests may be overfit to internals.
108
109	## Anti-Patterns
110
111	- writing tests after the implementation and calling it TDD
112	- changing the test to match a broken implementation
113	- asserting on private internals instead of behavior
114	- creating giant fixture setups for simple behavior
115	- using TDD language while skipping the red phase
116
117	## Output Contract
118
119	When reporting TDD progress, include:
120
121	- failing test added
122	- implementation change
123	- verification command
124	- refactor notes
125	- remaining coverage gaps
126
127	## Example Status Block
128
129	```markdown
130	TDD status:
131	- Red: added failing regression test for partially hydrated session redirect
132	- Green: updated middleware guard to wait for token presence
133	- Refactor: simplified session-check helper naming
134	- Verify: pytest

People who liked this also viewed

6 picks

Type

test-driven-development

132stars24forks

View on GitHub

How to install test-driven-development?

alexai-mcp/hermes-ccc/test-driven-development

$npx -y skills add AlexAI-MCP/hermes-CCC --skill test-driven-development

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Test-Driven Development
2
3	## Purpose
4
5	- Drive implementation from observable behavior.
6	- Reproduce bugs before fixing them.
7	- Keep code changes tightly coupled to expected outcomes.
8	- Use tests as design tools, not just safety nets.
9	- Reduce regressions by proving each behavior change.
10
11	## Activation Signals
12
13	- Use this skill when adding a new feature with clear acceptance behavior.
14	- Use this skill when fixing a bug that should never recur.
15	- Use this skill when API shape is easier to design from usage than internals.
16	- Use this skill when reviewers will ask for evidence.
17	- Use this skill when the codebase already has a strong test culture.
18
19	## Core Cycle
20
21	1. Write a failing test.
22	2. Run the smallest test scope and watch it fail for the right reason.
23	3. Implement the smallest change that makes it pass.
24	4. Re-run the test.
25	5. Refactor while keeping tests green.
26	6. Expand coverage only when a new behavior boundary appears.
27
28	## Red Phase
29
30	- Express one behavior at a time.
31	- Name the test after the behavior, not the implementation.
32	- Ensure the failure is caused by missing behavior, not a broken fixture.
33	- Keep setup minimal.
34	- Prefer explicit assertions over snapshot sprawl unless snapshots are already standard.
35	- For bug fixes, make the failing test mirror the actual defect.
36
37	## Green Phase
38
39	- Implement the smallest viable change.
40	- Do not optimize before the test passes.
41	- Avoid speculative abstractions.
42	- If several code paths fail, make one behavior pass first.
43	- Keep the first passing diff small enough to reason about.
44
45	## Refactor Phase
46
47	- Remove duplication exposed by the passing test.
48	- Improve names and structure.
49	- Preserve behavior while simplifying code.
50	- Re-run relevant tests after each meaningful refactor.
51	- Stop refactoring once readability improves and the tests still describe the behavior clearly.
52
53	## Bug-Fix TDD
54
55	- Reproduce the bug in a failing test before touching the fix.
56	- If reproduction is expensive, build a narrow harness.
57	- If the bug is timing-sensitive, isolate the timing dependency rather than sleeping more.
58	- If the bug cannot be reproduced, treat the fix as higher risk and document why.
59
60	## Test Selection Rules
61
62	- Use unit tests for pure behavior and deterministic branching.
63	- Use integration tests for component boundaries and data flow.
64	- Use end-to-end tests only when lower layers cannot express the guarantee.
65	- Put the regression test at the lowest layer that still captures the defect.
66
67	## Assertion Rules
68
69	- Assert the most important observable outcome first.
70	- Prefer stable assertions over implementation detail checks.
71	- Avoid asserting on incidental formatting unless formatting is the feature.
72	- For collections, assert the contract that matters: count, key values, order, or identity.
73
74	## Good Test Names
75
76	- `test_search_returns_ranked_results_for_partial_match`
77	- `test_login_redirect_does_not_loop_when_session_is_hydrated`
78	- `test_serializer_rejects_missing_required_field`
79
80	## Bad Test Names
81
82	- `test_fix`
83	- `test_works`
84	- `test_api`
85	- `test_stuff`
86
87	## Useful Commands
88
89	```bash
90	pytest tests/test_module.py::test_specific_behavior -vv
91	pytest tests/ -k "auth and redirect" -vv
92	ruff check path/to/file.py
93	```
94
95	## Design Benefits To Exploit
96
97	- Tests clarify API ergonomics.
98	- Tests reveal hidden dependencies.
99	- Tests pressure functions toward clean inputs and outputs.
100	- Tests expose when code is too coupled to mock cleanly.
101
102	## Decision Rules
103
104	- If a feature request has no acceptance behavior, clarify before writing code.
105	- If the first test is too hard to write, the design seam may be missing.
106	- If the code needed to pass the test is huge, the test scope is probably too broad.
107	- If refactoring requires changing many tests, the tests may be overfit to internals.
108
109	## Anti-Patterns
110
111	- writing tests after the implementation and calling it TDD
112	- changing the test to match a broken implementation
113	- asserting on private internals instead of behavior
114	- creating giant fixture setups for simple behavior
115	- using TDD language while skipping the red phase
116
117	## Output Contract
118
119	When reporting TDD progress, include:
120
121	- failing test added
122	- implementation change
123	- verification command
124	- refactor notes
125	- remaining coverage gaps
126
127	## Example Status Block
128
129	```markdown
130	TDD status:
131	- Red: added failing regression test for partially hydrated session redirect
132	- Green: updated middleware guard to wait for token presence
133	- Refactor: simplified session-check helper naming
134	- Verify: pytest

People who liked this also viewed

6 picks

Type