tdd_skill
- Shell
17
GitHub Stars
6
Bundled Files
2 months ago
Catalog Refreshed
4 months ago
First Indexed
Readme & install
Copy the install command, review bundled files from the catalogue, and read any extended description pulled from the listing source.
Installation
Preview and clipboard use veilstrat where the catalogue uses aiagentskills.
npx veilstrat add skill petekp/claude-code-setup --skill tdd- deep-modules.md1.2 KB
- interface-design.md653 B
- mocking.md1.4 KB
- refactoring.md387 B
- SKILL.md4.1 KB
- tests.md1.6 KB
Overview
This skill guides developers through test-driven development using the red-green-refactor loop, focused on behavior-first, integration-style tests. It emphasizes vertical tracer-bullet cycles: one failing test, minimal implementation to pass, then refactor. Use it to build features or fix bugs with test-first discipline.
How this skill works
I steer you through planning, writing a single end-to-end test (the tracer bullet), implementing the smallest amount of code to make that test pass, and then refactoring safely. Tests should exercise public interfaces and describe observable behavior so they survive internal changes. The loop repeats until the targeted behaviors are covered, then you run a disciplined refactor step with tests green.
When to use it
- Starting a new feature and you want test-first development
- Fixing a bug and verifying behavior before changing code
- When you need integration-style tests that exercise public APIs
- When you want to avoid speculative or implementation-coupled tests
- When you need a repeatable red→green→refactor workflow for quality
Best practices
- Write tests against the public interface only; avoid mocking internal collaborators
- Do one test → one implement → repeat; avoid writing many tests up front
- Keep each implementation minimal to satisfy the current test—no speculative features
- Use tracer bullets: start with a single end-to-end test that validates the path
- Only refactor after tests are green and run tests after each refactor step
Example use cases
- Add checkout flow: write a test that a user can complete checkout, implement minimal handlers, then refactor
- Fix flaky failure: write a failing integration test that reproduces the bug, implement fix, keep tests focused on behavior
- Expose a new public API: design the interface first, write tests for expected behavior, implement incrementally
- Convert brittle unit tests to integration-style tests that validate end-to-end behavior
- Iteratively develop complex logic behind a small interface using deep modules
FAQ
A good test verifies observable behavior through the public interface, reads like a spec, and continues to pass after internal refactors.
Should I mock dependencies?
Prefer real integrations for behavior tests; only mock external systems when isolation or speed is required, and avoid mocking internal collaborators.