test-driven-development

Test-first development is enforced by requiring a failing test before writing production code, following the Red-Green-Refactor cycle. You write a failing test, implement minimal code to pass it, and then refactor while keeping tests green.

The best way to fix a bug using test-driven development is to first write a failing test that reproduces the exact bug. Then, implement the minimal fix needed to make the test pass and re-run the full suite to prevent regressions.

Verifying that a test fails for the expected reason ensures your test actually targets the intended behavior before writing production code. Skipping this failure verification is treated as a shortcut violation that triggers a workflow restart.

Behavior-focused tests use clear test names and validate real code coverage rather than mock behavior or vague assertions. This ensures tests verify actual production requirements instead of implementation side-effects.

Yes, you can use test-driven development for refactoring existing code. The workflow applies to behavior changes and refactoring tasks by maintaining green tests while you improve the code structure, ensuring reliability and regression prevention.

Writing tests after implementation is treated as an anti-rationalization shortcut. The skill enforces strict test-first discipline, meaning this violation triggers a restart of the development cycle to maintain high-confidence changes.