test-driven-development

Drives implementation and bug fixes through test-first red-green-refactor cycles.

22|Updated Sep 10, 2026
One-click install
npx skills add https://github.com/Lynricsy/HyperSkills --skill test-driven-development-lynricsy
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: test-driven-development
Source: https://github.com/Lynricsy/HyperSkills/tree/main/skills/test-driven-development
Command: npx skills add https://github.com/Lynricsy/HyperSkills --skill test-driven-development-lynricsy

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve? Code written without tests first produces tests that pass on the first run and prove nothing, bug fixes ship without verified regression coverage, and test suites fill with change detectors and mock assertions that fail on refactors while sleeping through real bugs. ## Core Features & Use Cases - Red-green-refactor workflows: Guided implement-feature and fix-bug flows that require watching each test fail before writing code, discovering the repository's own test commands, and quoting real command output as evidence. - Regression proof for bug fixes: A mandatory revert-the-fix procedure that confirms a regression test fails without the fix and passes with it restored. - Test review with verdicts: A review-tests workflow that names the production change each test would catch and issues keep/rewrite/delete verdicts with file:line references, backed by catalogues of test smells, mocking rules, and test strategy guidance. - Use Case: Given a bug report that toSlug returns 'deploy----v2-' instead of 'deploy-v2', write a failing reproduction test using the repo's own make test command, fix the root cause, then revert and restore the fix to prove the regression test is real. ## Quick Start Ask the agent to implement a new function or fix a bug test-first, following the red-green-refactor loop and reporting the actual failing and passing test output.

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 real repository?

Discover the repository's own test commands first from package.json, Makefile, or CI config, then write one failing test per behaviour before any production code. Run the focused command to watch it fail, write the minimal implementation, and re-run to green, quoting both outputs.

How do I write a regression test for a bug fix?

Write a test that reproduces the bug and fails against the unchanged code before fixing anything. After the fix passes, revert only the fix, confirm the test fails again, then restore it and confirm it passes, quoting all three runs.

When is it acceptable to mock in unit tests?

Mock only at system boundaries: external services, the clock, randomness, and databases or filesystems that are genuinely too slow. Never mock your own modules, and never let a mock carry the assertion; assert the observable outcome instead.

Why do my tests pass but not catch real bugs?

Tests that compute expected values with the code under test, compare a function to itself, or assert only that a mock was called pass by construction and cannot disagree with the code. Each test must name a production change that would make it fail, and that change must be a bug, not a decision.

When should I not use test-driven development?

A throwaway spike whose code will be deleted may skip the loop, provided you say so up front and discard the spike. Test-runner APIs, browser end-to-end testing, CI configuration, and open-ended debugging are out of scope and belong to other skills.