tdd

Guides test-driven development using red-green-refactor cycles with behavior-focused integration tests.

2|1|Updated Jun 9, 2026
One-click install
npx skills add https://github.com/zester4/zilmate --skill tdd-zester4
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: tdd
Source: https://github.com/zester4/zilmate/tree/main/.agents/skills/tdd
Command: npx skills add https://github.com/zester4/zilmate --skill tdd-zester4

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Writing tests after implementation often produces brittle tests coupled to internal structure that break during refactors and fail to catch real regressions. This Skill enforces a disciplined test-first workflow so tests verify observable behavior through public interfaces and survive code changes. ## Core Features & Use Cases - Vertical Slice Workflow: Enforces one test then one implementation per cycle instead of writing all tests upfront, preventing speculative tests of imagined behavior. - Behavior-Focused Testing Guidance: Distinguishes good integration-style tests from implementation-coupled tests, with concrete TypeScript examples of each. - Mocking and Refactoring Rules: Defines when to mock (system boundaries only), how to design mockable interfaces via dependency injection, and what refactor candidates to look for after each green phase. - Use Case: When adding a checkout feature, write one failing test for a single behavior like cart confirmation, implement the minimal code to pass, then repeat for each remaining behavior before refactoring. ## Quick Start Ask the assistant to build a new feature using test-driven development with one red-green-refactor cycle per behavior.

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 on a new feature?

Write one failing test for a single behavior through the public interface, then write the minimal code to make it pass, and repeat per behavior. After all tests pass, refactor duplication and deepen modules while keeping tests green.

What is the difference between good and bad unit tests?

Good tests verify observable behavior through public APIs and survive internal refactors. Bad tests mock internal collaborators, test private methods, or assert on call counts, so they break when implementation changes without any behavior change.

When should I use mocks in testing?

Mock only at system boundaries such as external APIs, time, randomness, and sometimes databases or file systems. Never mock your own classes or internal collaborators, and design boundaries with dependency injection for easy mocking.

Why should I avoid writing all tests before implementation?

Writing all tests first produces tests of imagined behavior tied to data shapes and signatures rather than real behavior. Vertical slicing with one test then one implementation keeps each test grounded in what you just learned from the previous cycle.

When is it safe to refactor during TDD?

Refactor only after all tests pass, never while a test is failing. Look for duplication, long methods, shallow modules, feature envy, and primitive obsession, running tests after each refactor step.