test-driven-development

Name: test-driven-development
Author: DevelopersGlobal

64stars10forks

How to install test-driven-development?

developersglobal/ai-agent-skills/test-driven-development

$npx -y skills add DevelopersGlobal/ai-agent-skills --skill test-driven-development

Installs into the current project.

Summary

Red-green-refactor cycle with meaningful coverage. Tests are written before implementation. Coverage is a side effect of good tests, not the goal.

Files · 1

View on GitHub

SKILL.md

1	## Overview
2
3	TDD is the discipline of writing a failing test before writing implementation code. It forces you to think about the interface before the internals, produces tests that actually test behavior (not just coverage), and gives you a safety net for every refactor.
4
5	AI agents skip tests constantly. This skill makes tests non-optional.
6
7	## When to Use
8
9	- Starting any new feature or function
10	- Fixing any bug (write a test that reproduces the bug first)
11	- Refactoring existing code (ensure test coverage before you start)
12
13	## Process
14
15	### Step 1: Write a Failing Test (Red)
16
17	1. Write a test for the behavior you want — before writing implementation.
18	2. The test should describe what the code does, not how:
19	- ✅ `test("returns 404 when user not found")`
20	- ❌ `test("calls findById with the user id")`
21	3. Run the test. Confirm it fails for the right reason (not a syntax error — a missing implementation).
22
23	Verify: Test runs and fails with a clear "not implemented" or "undefined" error.
24
25	### Step 2: Write Minimum Code (Green)
26
27	4. Write the minimum implementation to make the test pass.
28	5. Do not write more than the test requires — resist the urge to add logic for future cases.
29	6. Run the test. Confirm it passes.
30
31	Verify: All tests pass. No new tests added yet.
32
33	### Step 3: Refactor (Refactor)
34
35	7. Now clean up the implementation — no new behavior, only improved structure.
36	8. Run tests after every refactoring step — do not batch refactors.
37	9. If tests break during refactor: revert immediately, refactor more carefully.
38
39	Verify: Tests still pass after refactor. Code is cleaner.
40
41	### Step 4: Repeat for Each Behavior
42
43	10. Repeat steps 1–3 for each distinct behavior of the feature.
44	11. Test pyramid: many unit tests, fewer integration tests, minimal end-to-end tests.
45
46	### Step 5: Coverage Sanity Check
47
48	12. Run coverage report. Flag any critical paths with 0% coverage.
49	13. Do NOT chase a coverage number — write tests for behaviors that matter.
50
51	Verify: All happy paths and key edge cases have tests. Coverage report reviewed.
52
53	## Common Rationalizations (and Rebuttals)
54
55	\| Excuse \| Rebuttal \|
56	\|--------\|----------\|
57	\| "I'll add tests after" \| After never comes. And after-the-fact tests test your implementation, not the behavior. \|
58	\| "This code is too simple to test" \| Simple code breaks in unexpected ways when requirements change. \|
59	\| "Integration tests are enough" \| Unit tests catch bugs faster, run faster, and localize failures better. \|
60	\| "We don't have time for TDD" \| You have time for the bug investigation that comes without TDD? \|
61
62	## Red Flags
63
64	- Tests were written after the implementation
65	- Tests test internal implementation details (private methods, DB queries) rather than behavior
66	- "Happy path only" test coverage
67	- Tests pass even when you break the implementation (mocked away the real behavior)
68	- Coverage target hit by testing trivial getters/setters
69
70	## Verification
71
72	- [ ] Tests written before implementation (or alongside for bug fixes)
73	- [ ] Each test describes a specific behavior
74	- [ ] Red-green-refactor cycle followed
75	- [ ] All tests pass
76	- [ ] Key edge cases covered (empty input, null, boundary values)
77	- [ ] Coverage report reviewed for critical path gaps
78
79	## References
80
81	- [debugging-methodology skill](../debugging-methodology/SKILL.md)
82	- [references/testing-patterns.md](../../references/testing-patterns.md)

People who liked this also viewed

6 picks

Type

test-driven-development

64stars10forks

View on GitHub

How to install test-driven-development?

developersglobal/ai-agent-skills/test-driven-development

$npx -y skills add DevelopersGlobal/ai-agent-skills --skill test-driven-development

Installs into the current project.

Summary

Red-green-refactor cycle with meaningful coverage. Tests are written before implementation. Coverage is a side effect of good tests, not the goal.

Files · 1

View on GitHub

SKILL.md

1	## Overview
2
3	TDD is the discipline of writing a failing test before writing implementation code. It forces you to think about the interface before the internals, produces tests that actually test behavior (not just coverage), and gives you a safety net for every refactor.
4
5	AI agents skip tests constantly. This skill makes tests non-optional.
6
7	## When to Use
8
9	- Starting any new feature or function
10	- Fixing any bug (write a test that reproduces the bug first)
11	- Refactoring existing code (ensure test coverage before you start)
12
13	## Process
14
15	### Step 1: Write a Failing Test (Red)
16
17	1. Write a test for the behavior you want — before writing implementation.
18	2. The test should describe what the code does, not how:
19	- ✅ `test("returns 404 when user not found")`
20	- ❌ `test("calls findById with the user id")`
21	3. Run the test. Confirm it fails for the right reason (not a syntax error — a missing implementation).
22
23	Verify: Test runs and fails with a clear "not implemented" or "undefined" error.
24
25	### Step 2: Write Minimum Code (Green)
26
27	4. Write the minimum implementation to make the test pass.
28	5. Do not write more than the test requires — resist the urge to add logic for future cases.
29	6. Run the test. Confirm it passes.
30
31	Verify: All tests pass. No new tests added yet.
32
33	### Step 3: Refactor (Refactor)
34
35	7. Now clean up the implementation — no new behavior, only improved structure.
36	8. Run tests after every refactoring step — do not batch refactors.
37	9. If tests break during refactor: revert immediately, refactor more carefully.
38
39	Verify: Tests still pass after refactor. Code is cleaner.
40
41	### Step 4: Repeat for Each Behavior
42
43	10. Repeat steps 1–3 for each distinct behavior of the feature.
44	11. Test pyramid: many unit tests, fewer integration tests, minimal end-to-end tests.
45
46	### Step 5: Coverage Sanity Check
47
48	12. Run coverage report. Flag any critical paths with 0% coverage.
49	13. Do NOT chase a coverage number — write tests for behaviors that matter.
50
51	Verify: All happy paths and key edge cases have tests. Coverage report reviewed.
52
53	## Common Rationalizations (and Rebuttals)
54
55	\| Excuse \| Rebuttal \|
56	\|--------\|----------\|
57	\| "I'll add tests after" \| After never comes. And after-the-fact tests test your implementation, not the behavior. \|
58	\| "This code is too simple to test" \| Simple code breaks in unexpected ways when requirements change. \|
59	\| "Integration tests are enough" \| Unit tests catch bugs faster, run faster, and localize failures better. \|
60	\| "We don't have time for TDD" \| You have time for the bug investigation that comes without TDD? \|
61
62	## Red Flags
63
64	- Tests were written after the implementation
65	- Tests test internal implementation details (private methods, DB queries) rather than behavior
66	- "Happy path only" test coverage
67	- Tests pass even when you break the implementation (mocked away the real behavior)
68	- Coverage target hit by testing trivial getters/setters
69
70	## Verification
71
72	- [ ] Tests written before implementation (or alongside for bug fixes)
73	- [ ] Each test describes a specific behavior
74	- [ ] Red-green-refactor cycle followed
75	- [ ] All tests pass
76	- [ ] Key edge cases covered (empty input, null, boundary values)
77	- [ ] Coverage report reviewed for critical path gaps
78
79	## References
80
81	- [debugging-methodology skill](../debugging-methodology/SKILL.md)
82	- [references/testing-patterns.md](../../references/testing-patterns.md)

People who liked this also viewed

6 picks

Type