test-driven-development

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

Updated Sep 5, 2026
One-click install
npx skills add https://github.com/nntoan/ultra-omp --skill test-driven-development-nntoan
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: test-driven-development
Source: https://github.com/nntoan/ultra-omp/tree/main/packages/proflow/skills/test-driven-development
Command: npx skills add https://github.com/nntoan/ultra-omp --skill test-driven-development-nntoan

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Code changes often ship without proof they work, and bug fixes regress silently because no test captured the failure. This Skill enforces a disciplined test-first workflow so every behavior change is verified by a failing-then-passing test. ## Core Features & Use Cases - RED-GREEN-REFACTOR Cycle: Write a failing test first, implement the minimal code to pass it, then refactor with tests as a safety net. - 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 commands (npm, Gradle, pytest, Cargo, Go) instead of assuming defaults. - Use Case: A bug report says completing a task doesn't set its timestamp. Write a reproduction test that fails, implement the fix, watch it pass, then run the full suite to confirm no regressions. ## Quick Start Ask the agent to implement a new feature or fix a bug using test-driven development with a failing test written first.

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 verify no regressions were introduced.

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

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

Should tests use mocks or real implementations?▼

Prefer real implementations first, then fakes, stubs, and mocks last. Mock only when the real dependency is too slow, non-deterministic, or has uncontrollable side effects like external APIs or email sending.

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 tests that pass on the first run signal a problem?▼

A test that passes immediately proves nothing about the new behavior, since it may not exercise the code you think it does. A proper TDD test must fail first, confirming it actually detects the missing behavior.