test-driven-development

Drives production code from failing tests through the red-green-refactor cycle.

Updated Nov 20, 2025
One-click install
npx skills add https://github.com/apuya/react-basics-ui --skill test-driven-development-apuya
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: test-driven-development
Source: https://github.com/apuya/react-basics-ui/tree/main/.claude/skills/test-driven-development
Command: npx skills add https://github.com/apuya/react-basics-ui --skill test-driven-development-apuya

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Writing tests after the fact produces suites that mirror implementation details, miss edge cases, and break on harmless refactors. This Skill enforces test-first development so every behaviour is specified by a failing test before any production code exists, and keeps existing suites fast, deterministic, and trustworthy. ## Core Features & Use Cases - Red-Green-Refactor Cycle: Writes one failing test per behaviour, the minimum code to pass it, then refactors with the suite green, with each step shown separately. - Scope Selection: Chooses between unit, integration, contract, and end-to-end tests based on what must fail when the behaviour breaks, including component-library-specific scopes like boundary and mutation tests. - Suite Auditing: Detects assertion-free tests, shared mutable state, ordering dependencies, over-mocking, and coverage that measures lines instead of behaviour, with tiered findings and fixes. - Legacy Recovery: Pins current behaviour with characterisation tests before changing untested code, then resumes the normal cycle from a green baseline. - Use Case: When adding a feature to a React component library, use this Skill to plan the ordered list of behaviours, drive each one with a failing Vitest test, and audit the resulting suite for flaky or brittle tests. ## Quick Start Use test-driven development to add a new behaviour to my component, starting with a failing test that specifies the expected outcome.

Frequently Asked Questions about test-driven-development

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

FAQPage Schema
How do I start test-driven development on a new feature?

Begin by stating the behaviour in one sentence, then write the smallest test that asserts it and watch it fail for the expected reason. Write the minimum code to pass, run the full suite, then refactor while tests stay green before starting the next behaviour.

What is the difference between a mock, stub, fake, and spy?

Stubs return canned answers to inbound queries, fakes are simpler real implementations for stateful collaborators, spies record outbound calls for later assertion, and mocks carry pre-programmed expectations that fail the test if unmet. Choose by the purpose the double serves, not by name.

How do I add tests to legacy code that has none?

Write characterisation tests that pin current behaviour, including quirks, and confirm they all pass before changing anything. Then find a seam such as a constructor parameter or method, resume the normal red-green-refactor cycle, and delete characterisation tests once proper specification tests replace them.

Why are my tests flaky and how do I fix them?

Flakiness comes from uncontrolled time, randomness, shared mutable state, ordering dependencies, or race conditions. Inject clocks and randomness as dependencies, reset state between tests, and fix or quarantine flaky tests with an owner and deadline rather than ignoring them.

When should I use unit tests versus integration or end-to-end tests?

Default to the smallest scope that can fail for the reason you are testing: unit tests for decisions and transformations, integration tests when behaviour depends on a real dependency's semantics, and end-to-end tests only for smoke-level confidence. Many fast unit tests with few end-to-end tests keeps the suite runnable on every change.

Is high code coverage a sign of a good test suite?

No. Line coverage measures what executed, not what was specified; a suite can hit 100% coverage with zero meaningful assertions. Use coverage to find untested code, and consider mutation testing to reveal tests that execute code without specifying its behaviour.