Test-Driven Development (Spec Kit Plus)

Test-driven development requires writing a failing test first that demonstrates the missing feature or reproduces the bug before changing any production code, ensuring your implementation is evidence-based and requirement-complete.

The Red-Green-Refactor loop in test-first development guides you to write a failing test, implement the minimum production code to make it pass, and then refactor without introducing new behavior to prevent regressions.

Writing a failing test before production code prevents incomplete or fragile implementations by verifying requirements empirically first, which reduces debugging churn and prevents unverified production edits.

Yes, test-driven development applies to refactoring by ensuring you have a passing test confirming current behavior before you refactor, preventing new behavior from being introduced and stopping regressions.

Spec-driven workflows apply specifically to sp-implement, sp-debug, sp-fast, and sp-quick tasks, ensuring your first debugging or implementation step is evidence-based and starts with a failing test.

Enforcing a test-first development workflow strictly prohibits making any unverified production edits before empirically confirming a test failure, which may slow down rapid prototyping when requirements are completely undefined.