test-driven-development
This skill teaches the red-green-refactor cycle: write a failing test, verify it fails for the right reason, implement just enough code to pass, then refactor. Follow the iron law—no production code without a failing test first—and use this approach for all features, bug fixes, and refactoring work.
Test-Driven Development guides you through writing failing tests first, then minimal code to pass them, ensuring every feature is properly tested.
AI-generated summary based on this skill's SKILL.md
Install
ShaftHQ/SHAFT_ENGINE/test-driven-development · repository language: Java
git clone https://github.com/ShaftHQ/SHAFT_ENGINE
cp -r SHAFT_ENGINE/.claude/skills/test-driven-development ~/.claude/skills/test-driven-developmentFrequently asked questions
AI-generated answers based on this skill's SKILL.md and metadata
What is the red-green-refactor cycle in test-driven development?
test-driven-development teaches the red-green-refactor cycle as the core TDD workflow. Red: write a failing test and verify it fails for the right reason. Green: implement just enough code to pass the test. Refactor: improve the code while keeping tests passing. This cycle repeats for every feature, bug fix, and refactoring task, ensuring no production code is written without a failing test first.
How do you write tests first in test-driven development?
In test-driven-development, writing tests first means authoring test cases before any implementation code exists. Start by defining what behavior you want—write a test that describes it. Run the test and watch it fail (red phase). Then write minimal code to make it pass (green phase). This test-first approach ensures your code is testable, focused, and directly addresses real requirements.
What does test-driven-development say about failing tests before code?
test-driven-development follows an iron law: no production code without a failing test first. Always write a failing test, verify it fails for the right reason, then implement code to pass it. This discipline ensures every line of production code is driven by a real test requirement and prevents writing untested or unnecessary code.
How does test-driven-development help with bug fixes?
test-driven-development applies TDD for bug fixes by writing a failing test that reproduces the bug, then fixing the code to pass that test. This approach captures the bug as a test case, prevents regression, and ensures the fix is verified. The same red-green-refactor cycle applies: failing test, minimal fix, then refactor if needed.
What testing anti-patterns does test-driven-development help you avoid?
test-driven-development teaches you to avoid common TDD mistakes and testing anti-patterns. By following the discipline of writing failing tests first and implementing only enough code to pass them, you prevent brittle tests, over-engineered code, untested paths, and false confidence. The methodology keeps you focused on real behavior verification rather than test coverage theater.
Can you refactor safely with test-driven-development?
test-driven-development enables safe refactoring through test coverage. Once you have a comprehensive test suite from following the red-green-refactor cycle, you can refactor code with confidence—your tests verify that behavior remains correct. The skill teaches refactoring as the final phase of TDD, where you improve code quality while maintaining all passing tests.
SKILL.md
rendered from the published skill — quoted content, verbatim
Test-Driven Development (TDD)
Overview
Write the test first. Watch it fail. Write minimal code to pass.
Core principle: If you didn't watch the test fail, you don't know if it tests the right thing.
Violating the letter of the rules is violating the spirit of the rules.
When to Use
Always: - New features - Bug fixes - Refactoring - Behavior changes
Exceptions (ask your human partner): - Throwaway prototypes - Generated code - Configuration files
Thinking "skip TDD just this once"? Stop. That's rationalization.
The Iron Law
NO PRODUCTION CODE WITHOUT A FAILING TEST FIRST
Write code before the test? Delete it. Start over.
No exceptions: - Don't keep it as "reference" - Don't "adapt" it while writing tests - Don't look at it - Delete means delete
Implement fresh from tests. Period.
Red-Green-Refactor
RED → verify it fails for the right reason → GREEN → verify it passes with everything else still green → REFACTOR → repeat. A wrong failure sends you back to RED; a failure after GREEN sends you back
(truncated - see the full file via the links below)
Read as markdown · JSON record · Browse the source repository
File tree — 4 files
.claude/skills/test-driven-development/LICENSE
.claude/skills/test-driven-development/SKILL.md
.claude/skills/test-driven-development/resisting-rationalization.md
.claude/skills/test-driven-development/testing-anti-patterns.md