test-driven-development

Guides implementation of code changes using the red-green-refactor test-driven development cycle.

5|Updated Feb 12, 2026
One-click install
npx skills add https://github.com/PHenrique07/Sementis-IFSP-Pirituba --skill test-driven-development-phenrique07
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: test-driven-development
Source: https://github.com/PHenrique07/Sementis-IFSP-Pirituba/tree/main/.github/skills/test-driven-development
Command: npx skills add https://github.com/PHenrique07/Sementis-IFSP-Pirituba --skill test-driven-development-phenrique07

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Code changes made without tests are unproven, and bug fixes without reproduction tests often regress later. This Skill enforces a disciplined workflow where every behavior change is proven by a failing test first, so fixes and features are verifiable rather than assumed correct. ## Core Features & Use Cases - Red-Green-Refactor Loop: Write a failing test, implement the minimal code to pass it, then refactor with tests staying green. - Prove-It Pattern for Bugs: Reproduce any reported bug with a failing test before attempting a fix, guaranteeing the fix actually works. - Stack Discovery: Detects the repository's own test framework and commands (pytest, Jest, Gradle, Cargo, go test) instead of assuming defaults. - Use Case: A bug report says completing a task does not set its timestamp. The Skill writes a failing reproduction test, implements the fix, confirms the test passes, and runs the full suite to rule out regressions. ## Quick Start Use test-driven development to fix this bug by first writing a failing test that reproduces it, then implementing the fix and running the full test suite.

Frequently Asked Questions about test-driven-development

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

FAQPage Schema
How do I practice test-driven development on a bug fix?▼

Write a test that reproduces the bug and confirm it fails before touching the fix. Then implement the minimal change until the test passes, and run the full suite to confirm no regressions. This is the Prove-It Pattern.

How to find the right test command for a repository?▼

Inspect the build files such as package.json, pyproject.toml, go.mod, or build.gradle, plus README and CI workflows. Prefer checked-in wrappers like ./gradlew or make test over assuming a default like npm test.

Should tests use mocks or real implementations?▼

Prefer real implementations first, then fakes, stubs, and mocks last. Mock only at boundaries where dependencies are slow, non-deterministic, or have uncontrollable side effects like external APIs or email sending.

When should I not write tests for a change?▼

Skip TDD for pure configuration changes, documentation updates, or static content with no behavioral impact. Any change affecting logic, behavior, or edge cases should have a corresponding test.

Why do my tests break every time I refactor code?▼

Tests that verify internal method calls or implementation details break on refactoring even when behavior is unchanged. Assert on inputs and outputs (state-based testing) instead of interaction sequences.