tdd

Name: tdd
Author: tt-a1i

16stars3forks

How to install tdd?

tt-a1i/matt-skills-with-to-goal/tdd

$npx -y skills add tt-a1i/matt-skills-with-to-goal --skill tdd

Installs into the current project.

Summary

Test-driven development. Use when the user wants to build features or fix bugs test-first, mentions "red-green-refactor", or wants integration tests.

Files · 1

View on GitHub

SKILL.md

1	# Test-Driven Development
2
3	TDD is the red → green loop. This skill is the reference that makes that loop produce tests worth keeping: what a good test is, where tests go, the anti-patterns, and the rules of the loop. Every section applies on every cycle — consult them before and during the loop, not after.
4
5	When exploring the codebase, read `CONTEXT.md` (if it exists) so test names and interface vocabulary match the project's domain language, and respect ADRs in the area you're touching.
6
7	## What a good test is
8
9	Tests verify behavior through public interfaces, not implementation details. Code can change entirely; tests shouldn't. A good test reads like a specification — "user can checkout with valid cart" tells you exactly what capability exists — and survives refactors because it doesn't care about internal structure.
10
11	See [tests.md](tests.md) for examples and [mocking.md](mocking.md) for mocking guidelines.
12
13	## Seams — where tests go
14
15	A seam is the public boundary you test at: the interface where you observe behavior without reaching inside. Tests live at seams, never against internals.
16
17	Test only at pre-agreed seams. Before writing any test, write down the seams under test and confirm them with the user. No test is written at an unconfirmed seam. You can't test everything — agreeing the seams up front is how testing effort lands on the critical paths and complex logic instead of every edge case.
18
19	Ask: "What's the public interface, and which seams should we test?"
20
21	## Anti-patterns
22
23	- Implementation-coupled — mocks internal collaborators, tests private methods, or verifies through a side channel (querying the database instead of using the interface). The tell: the test breaks when you refactor but behavior hasn't changed.
24	- Tautological — the assertion recomputes the expected value the way the code does (`expect(add(a, b)).toBe(a + b)`, a snapshot derived by hand the same way, a constant asserted equal to itself), so it passes by construction and can never disagree with the code. Expected values must come from an independent source of truth — a known-good literal, a worked example, the spec.
25	- Horizontal slicing — writing all tests first, then all implementation. Bulk tests verify _imagined_ behavior: you test the _shape_ of things rather than user-facing behavior, the tests go insensitive to real changes, and you commit to test structure before understanding the implementation. Work in vertical slices instead — one test → one implementation → repeat, each test a tracer bullet that responds to what the last cycle taught you.
26
27	## Rules of the loop
28
29	- Red before green. Write the failing test first, then only enough code to pass it. Don't anticipate future tests or add speculative features.
30	- One slice at a time. One seam, one test, one minimal implementation per cycle.
31	- Refactoring is not part of the loop. It belongs to the review stage (see the `code-review` skill), not the red → green implementation cycle.

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

16stars3forks

View on GitHub

How to install tdd?

tt-a1i/matt-skills-with-to-goal/tdd

$npx -y skills add tt-a1i/matt-skills-with-to-goal --skill tdd

Installs into the current project.

Summary

Test-driven development. Use when the user wants to build features or fix bugs test-first, mentions "red-green-refactor", or wants integration tests.

Files · 1

View on GitHub

SKILL.md

1	# Test-Driven Development
2
3	TDD is the red → green loop. This skill is the reference that makes that loop produce tests worth keeping: what a good test is, where tests go, the anti-patterns, and the rules of the loop. Every section applies on every cycle — consult them before and during the loop, not after.
4
5	When exploring the codebase, read `CONTEXT.md` (if it exists) so test names and interface vocabulary match the project's domain language, and respect ADRs in the area you're touching.
6
7	## What a good test is
8
9	Tests verify behavior through public interfaces, not implementation details. Code can change entirely; tests shouldn't. A good test reads like a specification — "user can checkout with valid cart" tells you exactly what capability exists — and survives refactors because it doesn't care about internal structure.
10
11	See [tests.md](tests.md) for examples and [mocking.md](mocking.md) for mocking guidelines.
12
13	## Seams — where tests go
14
15	A seam is the public boundary you test at: the interface where you observe behavior without reaching inside. Tests live at seams, never against internals.
16
17	Test only at pre-agreed seams. Before writing any test, write down the seams under test and confirm them with the user. No test is written at an unconfirmed seam. You can't test everything — agreeing the seams up front is how testing effort lands on the critical paths and complex logic instead of every edge case.
18
19	Ask: "What's the public interface, and which seams should we test?"
20
21	## Anti-patterns
22
23	- Implementation-coupled — mocks internal collaborators, tests private methods, or verifies through a side channel (querying the database instead of using the interface). The tell: the test breaks when you refactor but behavior hasn't changed.
24	- Tautological — the assertion recomputes the expected value the way the code does (`expect(add(a, b)).toBe(a + b)`, a snapshot derived by hand the same way, a constant asserted equal to itself), so it passes by construction and can never disagree with the code. Expected values must come from an independent source of truth — a known-good literal, a worked example, the spec.
25	- Horizontal slicing — writing all tests first, then all implementation. Bulk tests verify _imagined_ behavior: you test the _shape_ of things rather than user-facing behavior, the tests go insensitive to real changes, and you commit to test structure before understanding the implementation. Work in vertical slices instead — one test → one implementation → repeat, each test a tracer bullet that responds to what the last cycle taught you.
26
27	## Rules of the loop
28
29	- Red before green. Write the failing test first, then only enough code to pass it. Don't anticipate future tests or add speculative features.
30	- One slice at a time. One seam, one test, one minimal implementation per cycle.
31	- Refactoring is not part of the loop. It belongs to the review stage (see the `code-review` skill), not the red → green implementation cycle.

People who liked this also viewed

6 picks

Type