test-driven-development

Enforces red-green-refactor test-first workflow for features, bugfixes, and refactoring.

Updated May 21, 2026
One-click install
npx skills add https://github.com/CagesThrottleUs/private-ai-harness --skill test-driven-development-cagesthrottleus
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: test-driven-development
Source: https://github.com/CagesThrottleUs/private-ai-harness/tree/main/skills/test-driven-development
Command: npx skills add https://github.com/CagesThrottleUs/private-ai-harness --skill test-driven-development-cagesthrottleus

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve? Code written before tests produces unverified behavior, biased tests written after the fact, and regressions that slip into production. This Skill enforces a strict test-first discipline so every behavior change is proven by a failing test before implementation exists. ## Core Features & Use Cases - Red-Green-Refactor Cycle: Write one failing test, verify it fails for the right reason, write minimal code to pass, then refactor while staying green. - Test Design Strategies: Apply black-box techniques (boundary value analysis, equivalence partitioning, error guessing) and white-box techniques (branch, path, and condition coverage) to design tests that find errors rather than confirm success. - Rationalization Defense: Built-in counterarguments for common excuses like "too simple to test" or "I'll test after", plus a verification checklist covering mutation score gates, docstring requirements, and integration testing for external dependencies. - Use Case: When fixing a bug where empty emails are accepted, write a failing test asserting the rejection, watch it fail, implement the minimal validation, and confirm the suite passes before committing. ## Quick Start Ask the AI to implement a new feature or bugfix using strict test-driven development with a failing test written and verified 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 on a new feature?

Write one minimal failing test describing the desired behavior, run it to confirm it fails for the right reason, then write the simplest code that passes. Refactor only while tests stay green, and repeat the cycle for each new behavior.

How do I write tests that actually catch bugs?

Design tests to find errors using boundary value analysis, equivalence partitioning, and error guessing for edge cases like null, zero, and off-by-one inputs. After implementation, check branch and path coverage, and run a mutation testing tool like Stryker, PIT, or mutmut to prove tests fail on wrong code.

When is it acceptable to skip test-driven development?

Only for throwaway prototypes, generated code, or configuration files, and only with explicit approval from your human partner. Exploration is allowed, but the exploratory code must be discarded and rewritten test-first.

Why should I delete code written before its test?

Code written first can never be verified by a failing test, so you cannot prove the test catches the bug. Keeping it as reference biases the tests toward the existing implementation, which defeats the purpose of test-first design.

What is a good mutation score for a test suite?

A typical CI gate breaks below roughly 50 percent mutation score, with 60 to 80 percent targeted on load-bearing code. High line coverage with a low mutation score indicates tautological tests that execute code without verifying behavior.