test-driven-development

Guides test-first development using the RED-GREEN-REFACTOR cycle across any language or framework.

1|Updated Jul 5, 2026
One-click install
npx skills add https://github.com/yersonargotev/packy --skill test-driven-development-yersonargotev
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: test-driven-development
Source: https://github.com/yersonargotev/packy/tree/main/bundle/skills/test-driven-development
Command: npx skills add https://github.com/yersonargotev/packy --skill test-driven-development-yersonargotev

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve? Code changes made without tests ship unverified behavior, and bug fixes without reproduction tests leave regressions unguarded. This Skill enforces a disciplined write-the-failing-test-first workflow so every behavior change is proven by an executable test. ## Core Features & Use Cases - TDD Cycle Enforcement: Walks through RED (failing test), GREEN (minimal implementation), and REFACTOR steps, with repository-specific test command discovery before writing any test. - Prove-It Pattern for Bugs: Reproduces reported bugs with a failing test before attempting a fix, then verifies the fix and runs the full suite. - Testing Best Practices: Covers the test pyramid, test size classification, DAMP vs DRY, mock discipline, Arrange-Act-Assert, anti-patterns, and browser verification via Chrome DevTools. - Use Case: A bug report says completing a task doesn't set its timestamp. The Skill guides writing a failing reproduction test first, implementing the fix, and confirming the full suite passes. ## Quick Start Use the test-driven-development skill to implement this feature by writing a failing test first, then the minimal code to make it pass.

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 when fixing a bug?▼

Write a test that reproduces the bug first and confirm it fails, then implement the fix and confirm the test passes. Finally run the full test suite to check for regressions. This Prove-It Pattern guarantees the bug actually existed and the fix actually works.

How do I find the right test command for a repository?▼

Inspect the build files like package.json, pom.xml, pyproject.toml, go.mod, or Cargo.toml, and prefer checked-in wrappers such as ./gradlew or make test. README, CONTRIBUTING, and CI workflows show the commands that actually gate merges.

Should I use mocks or real implementations in unit tests?▼

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

What is the difference between unit, integration, and E2E tests?▼

Unit tests cover pure logic in milliseconds, integration tests cross boundaries like APIs or databases, and E2E tests verify critical user flows end to end. Aim for roughly 80% unit, 15% integration, and 5% E2E tests.

When should I not write tests for a change?▼

Skip tests only for pure configuration changes, documentation updates, or static content with no behavioral impact. Any change to logic, behavior, or edge case handling should have a corresponding test.

Why do my tests pass individually but fail when run together?▼

This indicates missing test isolation, where tests share mutable state or depend on execution order. Each test should set up and tear down its own state so it passes independently and in any order.