Add an observable feature
Describe what a caller should be able to do and test the result through the public interface.
TDD by Matt Pocock
Use TDD by Matt Pocock to implement a feature or fix through small, observable steps. Agree which public interfaces to test, write one failing behavior test, and add the minimum implementation needed to pass before choosing the next slice of work.
Install and get started
Choose your agent to see how to get started. In Floatboat, copy a request that asks the agent to read the original instructions. Other options show the Skill installation command or the publisher’s native setup steps.
Choose an agent
Start in Floatboat
Copy the request into a Floatboat conversation
Read the original TDD instructions at https://github.com/mattpocock/skills/blob/main/skills/engineering/tdd/SKILL.md. Explain its purpose, required tools, and installation options, then help me use it.Let the agent read the original instructions and check how to use them in your environment.
Download Floatboat ↗Try this request
Use Matt Pocock’s TDD for the checkout discount change. First propose the public testing seams, then implement one behavior at a time with a failing test.
About TDD
TDD is Matt Pocock’s reference Skill for test-first implementation through public interfaces. It asks the user and agent to agree the testing seams before writing tests, so effort goes toward meaningful behavior rather than private implementation details. Each cycle follows one failing test with one minimal implementation, then uses that feedback to choose the next slice. The current source explicitly separates refactoring into the review stage instead of bundling it into the red-to-green cycle. The collection includes testing and mocking references, while codebase-design supplies shared vocabulary when the interface itself is unsettled. An existing test environment and a clear behavior specification remain necessary.
Use Cases for TDD
Explore test-first work with a clear observable outcome. Add a feature behind a public interface, lock down a reproducible bug, or strengthen a critical integration path while keeping tests independent from internal structure and checking that each new test can detect the intended failure.
Protect a bug fix
Choose a test seam that actually reproduces the failure instead of asserting on unrelated internal details.
Cover a critical integration
Exercise the behavior spanning a meaningful boundary with known expected results.
How to Implement Behavior with TDD
Prepare the behavior specification and a runnable test command, then agree the public seams with your agent. Work through one failing test and one minimal implementation at a time, and keep broader cleanup for a separate review after the behavior is established.
- 01
Agree the test seams
Provide the required behavior and test command. Confirm which public interfaces matter and what each proposed test catches.
- 02
Run one red-to-green cycle
Write a test that fails for the intended reason, then implement only enough behavior to pass it.
- 03
Repeat and review separately
Use the last cycle’s evidence to choose the next slice. Review refactoring separately once the selected behavior works.
Explore More Agent Skills
Read another Skill guide and check its original source before using it.
TDD FAQ
What does this TDD Skill install?
It adds instructions and reference material to an agent. It does not install a test runner or configure a project’s dependencies.
Why agree seams before writing tests?
A seam identifies the public interface through which behavior is observed. Agreement helps prioritize critical paths and avoids tests coupled to private details.
Should all tests be written before implementation?
The source favors vertical slices: one test followed by its implementation, repeated as understanding improves. A batch of imagined tests can lock in the wrong structure.
Does the latest source include refactoring in every cycle?
No. The current source says refactoring belongs to the review stage rather than the red-to-green implementation loop. Earlier summaries may describe the familiar three-part phrase more loosely.
What makes an expected result trustworthy?
Use a specification, worked example, or known correct literal that is independent of the implementation. Recomputing the same algorithm in the assertion can hide the same bug.
When is codebase-design needed?
Use its reference when the public interface or module depth is itself unresolved. The collection treats it as shared design vocabulary rather than an additional interview session.
Can it guarantee complete test coverage?
No. It guides test selection and implementation; you still choose relevant behaviors and validate the resulting tests against the project’s risks.