tdd

Guides test-driven development through red-green-refactor cycles against public interfaces.

1|Updated Jun 29, 2026
One-click install
npx skills add https://github.com/Raynos/kami-kakushi --skill tdd-raynos
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: tdd
Source: https://github.com/Raynos/kami-kakushi/tree/main/.claude/skills/tdd
Command: npx skills add https://github.com/Raynos/kami-kakushi --skill tdd-raynos

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve? It prevents false-green test suites and implementation-coupled tests by enforcing a disciplined red-green-refactor workflow where every test verifies observable behavior through public interfaces before any implementation exists. ## Core Features & Use Cases - Vertical tracer-bullet workflow: Write one failing test, then the minimal code to pass it, repeating per behavior instead of writing all tests upfront. - Integration-style testing guidance: Drive the real game core and renderer (vitest with jsdom, the window.__qa harness) rather than mocking internal collaborators. - False-green detection: Mandate red-before-green and mutation-checking so tests actually fail when behavior breaks. - Use Case: When fixing a reproducible bug in the incremental RPG, reproduce it as a failing test first, implement the minimal fix, then refactor with the suite green. ## Quick Start Use the tdd skill to fix this bug by writing a failing test first, then the minimal implementation, then refactoring.

Frequently Asked Questions about tdd

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I practice test-driven development with red-green-refactor?

Write one failing test for a single behavior (red), write the minimal code to make it pass (green), then refactor while keeping tests green. Repeat per behavior rather than writing all tests upfront, which produces tests coupled to imagined structure.

What makes a good test versus a bad test in TDD?

Good tests verify observable behavior through public interfaces and survive internal refactors. Bad tests mock internal collaborators, test private methods, or assert on call counts, breaking whenever implementation changes without behavior changing.

When should I mock dependencies in unit tests?

Mock only at system boundaries like external APIs, databases, time, and file systems. Never mock your own classes or internal collaborators; in this codebase, randomness is handled by seeding the splitmix64 RNG rather than mocking.

How do I avoid false-green tests that never fail?

Require red before green: a new test must fail before implementation exists. When adding tests around working code, briefly break the implementation and confirm the test goes red, then restore it.

Should I write all tests before all implementation?

No. Horizontal slicing produces tests of imagined behavior that pass when behavior breaks. Use vertical tracer bullets: one test, one minimal implementation, repeated so each test responds to what the previous cycle revealed.