
Tdd
- 20 installs
- 22 repo stars
- Updated May 28, 2026
- acedergren/agentic-tools
tdd is a Claude Code skill that enforces a strict red-green-refactor test-first workflow for implementing features and fixing bugs.
About
This skill enforces a strict test-driven development cycle: red, green, refactor, commit. It requires writing failing tests before implementation, validating a mock bootstrap round-trip in mockReset:true projects, and running the full suite rather than a single file. A developer uses it when implementing a feature or fixing a bug test-first. It rejects tests that pass in the red phase and treats compile errors as invalid failures.
- Enforces a strict red-green-refactor test-first cycle
- Handles mock bootstrap for vitest/jest projects with mockReset:true
- Requires the full test suite to pass, not just the changed file
Tdd by the numbers
- 20 all-time installs (skills.sh)
- Ranked #1,435 of 2,153 Testing & QA skills by installs in the Skillselion catalog
- Data as of Jul 28, 2026 (Skillselion catalog sync)
tdd capabilities & compatibility
- Capabilities
- test first · unit testing · mock setup
- Use cases
- testing · debugging · refactoring
- Pricing
- Free
What tdd says it does
**NEVER write implementation before tests** — this is the entire point; skip it and the skill has no value
**Checkpoint**: All new tests MUST fail. If any pass → the behavior already exists or the test is wrong.
npx skills add https://github.com/acedergren/agentic-tools --skill tddAdd your badge
Show developers this skill is listed on Skillselion. Paste this into your README.
| Installs | 20 |
|---|---|
| repo stars | ★ 22 |
| Last updated | May 28, 2026 |
| Repository | acedergren/agentic-tools ↗ |
What it does
Implement a feature or bugfix test-first with a strict red-green-refactor cycle.
Who is it for?
Driving feature or bugfix implementation through a strict red-green-refactor cycle with mock bootstrap validation.
Skip if: Reviewing existing code or just running an existing test suite.
When should I use this skill?
When implementing features, fixing bugs, or adding deliberate test coverage test-first.
What you get
Each behavior change goes through a validated red-green-refactor loop with the full suite passing.
- Failing-first tests
- Minimal passing implementation
- Full green suite
By the numbers
- 6 NEVER rules
- Red-Green-Refactor-Commit 4-step cycle
Files
TDD Implementation Skill
When to Use
Load this skill when the user request matches the frontmatter description for TDD Implementation Skill.
Enforce a strict test-driven development cycle: Red → Green → Refactor → Commit.
NEVER
- NEVER write implementation before tests — this is the entire point; skip it and the skill has no value
- NEVER skip mock bootstrap validation — write one mock round-trip test first and confirm it passes before writing 20 tests
- NEVER skip the full test suite run — your file passing is not enough; regressions in unrelated files are your responsibility to notice
- NEVER proceed if tests pass in Red phase — a test that passes before implementation is testing nothing; revise it
- NEVER batch multiple features into one TDD cycle — one behavior change per red-green-refactor loop
- NEVER treat a compile/import error as "red" — tests must fail for the right reason (assertion failure, not broken setup)
Before Writing Any Tests
If `mockReset: true` in test runner config, most internet mock examples silently fail — return values clear between tests.
grep -rn 'mockReset\|mockClear\|restoreMocks' vitest.config.* jest.config.*If mockReset: true, you MUST reconfigure return values in beforeEach, not at module scope. Write ONE bootstrap test first to validate your mock wiring:
import { describe, it, expect, vi, beforeEach } from "vitest";
const mocks = vi.hoisted(() => ({
myDep: vi.fn(),
}));
vi.mock("../path/to/dependency", () => ({
myDep: (...args: unknown[]) => mocks.myDep(...args),
}));
describe("bootstrap", () => {
beforeEach(() => {
mocks.myDep.mockResolvedValue({ ok: true });
});
it("mock resolves correctly", async () => {
const { myDep } = await import("../path/to/dependency");
expect(await myDep()).toEqual({ ok: true });
});
});Run it, confirm it passes, then delete it and write the real tests using that same pattern.
Red Phase
Write tests covering: happy path, edge cases (empty/boundary inputs), error cases (invalid input, unauthorized, missing resource).
npx vitest run <test-file> --reporter=verboseCheckpoint: All new tests MUST fail. If any pass → the behavior already exists or the test is wrong.
Green Phase
Write the minimum code to make tests pass. No untested features, no premature optimization, no untested error handling.
npx vitest run <test-file> --reporter=verboseCheckpoint: All tests (new and existing) pass.
Full Suite
npx vitest run --reporter=verboseIf outside tests fail: determine if your change caused the regression. If yes → fix before proceeding. If pre-existing → note it and continue.
Refactor (Optional)
Only when tests are green. Extract helpers, improve naming, simplify conditionals. Re-run full suite after.
Quality Gates
npx eslint <changed-files>
npx tsc --noEmitFix before committing.
Mock Patterns Reference
Forwarding Pattern (survives mockReset)
const mockFn = vi.fn();
vi.mock("./dep", () => ({
dep: (...args: unknown[]) => mockFn(...args),
}));
beforeEach(() => {
mockFn.mockResolvedValue(defaultResult);
});Counter-Based Sequencing (multi-query operations)
let callCount = 0;
mockExecute.mockImplementation(async () => {
callCount++;
if (callCount === 1) return insertResult;
if (callCount === 2) return selectResult;
});globalThis Registry (TDZ workaround for interdependent mocks)
vi.mock("./dep", () => {
if (!(globalThis as any).__mocks) (globalThis as any).__mocks = {};
const m = { dep: vi.fn() };
(globalThis as any).__mocks.dep = m;
return { dep: (...a: unknown[]) => m.dep(...a) };
});
// In tests: const mocks = (globalThis as any).__mocks;Arguments
$ARGUMENTS: Optional description of what to implement via TDD- Example:
/tdd add rate limiting to the search endpoint - If empty: ask the user what to implement
Related skills
FAQ
What if a test passes in the red phase?
Revise it; a test that passes before implementation is testing nothing.
Is passing my own test file enough?
No; you must run the full suite because regressions in unrelated files are your responsibility to notice.