tdd

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

Updated Jun 29, 2026
One-click install
npx skills add https://github.com/iJosueeh/amauta --skill tdd-ijosueeh
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: tdd
Source: https://github.com/iJosueeh/amauta/tree/main/.agents/skills/tdd
Command: npx skills add https://github.com/iJosueeh/amauta --skill tdd-ijosueeh

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 verify real behavior. This Skill enforces a disciplined test-first workflow so tests describe observable behavior through public interfaces and survive code changes. ## Core Features & Use Cases - Vertical Slice Workflow: Enforces one test then one implementation per cycle (tracer bullets) instead of writing all tests upfront, preventing tests of imagined behavior. - Behavior-Focused Testing Guidance: Distinguishes good integration-style tests from implementation-coupled tests, with concrete examples of what to test and what to avoid. - Mocking and Refactoring Rules: Defines when to mock (system boundaries only) and provides a post-cycle refactor checklist covering duplication, module depth, and SOLID principles. - Use Case: When adding a checkout feature to an application, use this Skill to plan which behaviors to test, write one failing test, implement minimal code to pass, and repeat until the feature is complete. ## Quick Start Use the tdd skill to build the new shopping cart feature test-first, starting with one failing test for the add-item 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 effectively?

Follow red-green-refactor with vertical slices: write one failing test for a single behavior, write minimal code to pass it, then repeat for the next behavior. Avoid writing all tests upfront, which produces tests of imagined rather than actual behavior.

What is the difference between good and bad unit tests?

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 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, since that couples tests to implementation details.

Why do my tests break every time I refactor code?

Tests break during refactoring when they are coupled to implementation details like internal function names, private methods, or mock call expectations. Rewrite them to verify behavior through public interfaces so they only fail when actual behavior changes.

Should I write all tests before writing any implementation code?

No. Writing all tests first is horizontal slicing and produces tests of imagined behavior and data shapes. Use tracer bullets instead: alternate one test with one implementation so each test responds to what you learned from the previous cycle.