tdd

Name: tdd
Author: jmstar85

151stars12forks

How to install tdd?

jmstar85/oh-my-githubcopilot/tdd

$npx -y skills add jmstar85/oh-my-githubcopilot --skill tdd

Installs into the current project.

Summary

Test-Driven Development enforcement skill. Activates full TDD mode. Activate when: TDD, test-driven, test first, red-green-refactor, write tests first.

Files · 1

View on GitHub

SKILL.md

1	# TDD — Test-Driven Development
2
3	THE IRON LAW: Write the failing test FIRST. Always.
4
5	## The Red-Green-Refactor Cycle
6
7	```
8	RED → Write a failing test for the NEXT behavior
9	GREEN → Write ONLY enough code to make it pass (no extras)
10	REFACTOR → Clean up code quality (tests must stay green after every change)
11	REPEAT
12	```
13
14	## Step-by-Step Protocol
15
16	### 1. RED Phase
17	1. Identify the smallest next behavior to implement
18	2. Write a test that describes that behavior as a named `it()` / `test()` / `def test_`
19	3. Run the test — it MUST FAIL. If it passes, the test is wrong.
20	4. Confirm the failure message is the RIGHT failure (not a syntax error)
21
22	```typescript
23	// Example: RED — test fails because function doesn't exist yet
24	it('returns an empty array for an empty input', () => {
25	const result = parseItems([]);
26	expect(result).toEqual([]); // FAILS: parseItems is not defined
27	});
28	```
29
30	### 2. GREEN Phase
31	1. Write the MINIMUM code to make the test pass
32	2. Do not add extra logic, default parameters, or "nice-to-haves"
33	3. Run ALL tests — the new test must pass; existing tests must not break
34
35	```typescript
36	// Example: GREEN — just enough to pass
37	function parseItems(input: string[]): string[] {
38	return []; // only enough for the current test
39	}
40	```
41
42	### 3. REFACTOR Phase
43	1. Look at the code — can it be cleaner without changing behavior?
44	2. Apply simplification patterns (see `/ai-slop-cleaner` and `/coding-standards`)
45	3. Run tests after EVERY change. If tests break, undo immediately.
46
47	## TDD Gate — When to Stop
48
49	\| Situation \| Action \|
50	\|-----------\|--------\|
51	\| Code written before test \| STOP. Delete production code. Write test first. \|
52	\| Test passes on first run (no prior code) \| The test is wrong — fix it to fail first. \|
53	\| Multiple behaviors in one test \| STOP. One test, one behavior. \|
54	\| Skipping refactor to go faster \| Go back. Clean up before next feature. \|
55
56	## Naming Tests as Specifications
57
58	Tests are executable documentation. Name them as complete sentences:
59
60	```typescript
61	// BAD
62	it('test1', ...)
63	it('works with empty', ...)
64
65	// GOOD
66	it('returns empty array when input is empty', ...)
67	it('throws ValidationError when email is missing @', ...)
68	it('sends exactly one email when user registers', ...)
69	```
70
71	## Framework Quick Reference
72
73	\| Framework \| Failing assertion \| Run single test \|
74	\|-----------\|-------------------\|-----------------\|
75	\| Vitest \| `expect(x).toBe(y)` \| `npx vitest run -t "test name"` \|
76	\| Jest \| `expect(x).toBe(y)` \| `npx jest -t "test name"` \|
77	\| pytest \| `assert x == y` \| `pytest -k "test_name"` \|
78	\| cargo test \| `assert_eq!(x, y)` \| `cargo test test_name` \|
79	\| go test \| `t.Errorf(...)` \| `go test -run TestName` \|
80
81	## Common TDD Pitfalls
82
83	\| Pitfall \| Fix \|
84	\|---------\|-----\|
85	\| Testing implementation details \| Test behavior (outputs), not internals (private methods) \|
86	\| One test for 10 behaviors \| Split into atomic test cases \|
87	\| Mock everything (over-mocking) \| Mock at system boundaries only (DB, HTTP, filesystem) \|
88	\| No triangulation \| Write 2-3 tests that force the correct implementation to emerge \|
89	\| Untriangulated constants \| `return 42` passes one test — add a second test to force real logic \|
90
91	## See Also
92
93	- `@test-engineer` — test strategy, framework detection, coverage gap analysis
94	- `/ultraqa` — QA cycling: test, verify, fix, repeat
95	- `/verify` — evidence-based completion verification

People who liked this also viewed

6 picks

Type

tddSkills for Real Engineers. Straight from my .agents directory.SkillsJul 2026501k181k
test-driven-developmentUse when implementing any feature or bugfix, before writing implementation codeSkillsJul 2026175k259k
qaSkills for Real Engineers. Straight from my .agents directory.SkillsJul 2026160k181k
verification-before-completionUse when about to claim work is complete, fixed, or passing, before committing or creating PRs - requires running verification commands and confirming output before making any success claims; evidenceSkillsJul 2026153k259k
webapp-testingToolkit for interacting with and testing local web applications using Playwright. Supports verifying frontend functionality, debugging UI behavior, capturing browser screenshots, and viewing browser lSkillsJul 2026120k163k
playwright-best-practicesUse when writing Playwright tests, fixing flaky tests, debugging failures, implementing Page Object Model, configuring CI/CD, optimizing performance, mocking APIs, handling authentication or OAuth, teSkillsJul 202664k338

tdd

151stars12forks

View on GitHub

How to install tdd?

jmstar85/oh-my-githubcopilot/tdd

$npx -y skills add jmstar85/oh-my-githubcopilot --skill tdd

Installs into the current project.

Summary

Test-Driven Development enforcement skill. Activates full TDD mode. Activate when: TDD, test-driven, test first, red-green-refactor, write tests first.

Files · 1

View on GitHub

SKILL.md

1	# TDD — Test-Driven Development
2
3	THE IRON LAW: Write the failing test FIRST. Always.
4
5	## The Red-Green-Refactor Cycle
6
7	```
8	RED → Write a failing test for the NEXT behavior
9	GREEN → Write ONLY enough code to make it pass (no extras)
10	REFACTOR → Clean up code quality (tests must stay green after every change)
11	REPEAT
12	```
13
14	## Step-by-Step Protocol
15
16	### 1. RED Phase
17	1. Identify the smallest next behavior to implement
18	2. Write a test that describes that behavior as a named `it()` / `test()` / `def test_`
19	3. Run the test — it MUST FAIL. If it passes, the test is wrong.
20	4. Confirm the failure message is the RIGHT failure (not a syntax error)
21
22	```typescript
23	// Example: RED — test fails because function doesn't exist yet
24	it('returns an empty array for an empty input', () => {
25	const result = parseItems([]);
26	expect(result).toEqual([]); // FAILS: parseItems is not defined
27	});
28	```
29
30	### 2. GREEN Phase
31	1. Write the MINIMUM code to make the test pass
32	2. Do not add extra logic, default parameters, or "nice-to-haves"
33	3. Run ALL tests — the new test must pass; existing tests must not break
34
35	```typescript
36	// Example: GREEN — just enough to pass
37	function parseItems(input: string[]): string[] {
38	return []; // only enough for the current test
39	}
40	```
41
42	### 3. REFACTOR Phase
43	1. Look at the code — can it be cleaner without changing behavior?
44	2. Apply simplification patterns (see `/ai-slop-cleaner` and `/coding-standards`)
45	3. Run tests after EVERY change. If tests break, undo immediately.
46
47	## TDD Gate — When to Stop
48
49	\| Situation \| Action \|
50	\|-----------\|--------\|
51	\| Code written before test \| STOP. Delete production code. Write test first. \|
52	\| Test passes on first run (no prior code) \| The test is wrong — fix it to fail first. \|
53	\| Multiple behaviors in one test \| STOP. One test, one behavior. \|
54	\| Skipping refactor to go faster \| Go back. Clean up before next feature. \|
55
56	## Naming Tests as Specifications
57
58	Tests are executable documentation. Name them as complete sentences:
59
60	```typescript
61	// BAD
62	it('test1', ...)
63	it('works with empty', ...)
64
65	// GOOD
66	it('returns empty array when input is empty', ...)
67	it('throws ValidationError when email is missing @', ...)
68	it('sends exactly one email when user registers', ...)
69	```
70
71	## Framework Quick Reference
72
73	\| Framework \| Failing assertion \| Run single test \|
74	\|-----------\|-------------------\|-----------------\|
75	\| Vitest \| `expect(x).toBe(y)` \| `npx vitest run -t "test name"` \|
76	\| Jest \| `expect(x).toBe(y)` \| `npx jest -t "test name"` \|
77	\| pytest \| `assert x == y` \| `pytest -k "test_name"` \|
78	\| cargo test \| `assert_eq!(x, y)` \| `cargo test test_name` \|
79	\| go test \| `t.Errorf(...)` \| `go test -run TestName` \|
80
81	## Common TDD Pitfalls
82
83	\| Pitfall \| Fix \|
84	\|---------\|-----\|
85	\| Testing implementation details \| Test behavior (outputs), not internals (private methods) \|
86	\| One test for 10 behaviors \| Split into atomic test cases \|
87	\| Mock everything (over-mocking) \| Mock at system boundaries only (DB, HTTP, filesystem) \|
88	\| No triangulation \| Write 2-3 tests that force the correct implementation to emerge \|
89	\| Untriangulated constants \| `return 42` passes one test — add a second test to force real logic \|
90
91	## See Also
92
93	- `@test-engineer` — test strategy, framework detection, coverage gap analysis
94	- `/ultraqa` — QA cycling: test, verify, fix, repeat
95	- `/verify` — evidence-based completion verification

People who liked this also viewed

6 picks

Type