tdd-workflow

mkaczkowski's avatarfrom mkaczkowski

Test-Driven Development guidance. Use during feature-dev Phase 5 (Implementation) or any code implementation. Ensures tests are written BEFORE implementation code, following Red-Green-Refactor cycle.

⭐0stars🔀0forks📁View on GitHub🕐Updated Dec 29, 2025
[Testing and QA]

When & Why to Use This Skill

This Claude skill provides a structured Test-Driven Development (TDD) workflow designed to enhance software quality and maintainability. By guiding developers through the rigorous Red-Green-Refactor cycle, it ensures that tests are written before implementation code, leading to higher test coverage, fewer bugs, and more robust software architecture.

Use Cases

  • Feature Implementation: Guiding the development of new components, hooks, or utilities by mandating a failing test (Red) before writing any functional code.
  • Bug Fixing and Regression Testing: Ensuring that reported bugs are reproduced with a test case first, preventing future regressions and verifying the fix through the TDD cycle.
  • Code Refactoring: Providing a safety net for cleaning up and optimizing existing codebases by relying on pre-existing tests to maintain functional integrity during the Refactor phase.
  • Enforcing Project Standards: Maintaining strict adherence to project-specific testing requirements, such as 80% code coverage and the co-location of test files with source code.
nametdd-workflow
descriptionTest-Driven Development guidance. Use during feature-dev Phase 5 (Implementation) or any code implementation. Ensures tests are written BEFORE implementation code, following Red-Green-Refactor cycle.

TDD Workflow

CRITICAL: Tests First

During implementation, you MUST write tests before writing implementation code. This is non-negotiable.

The Red-Green-Refactor Cycle

RED: Write Failing Test

  1. Write a test for ONE piece of expected behavior
  2. Run the test - it MUST fail
  3. Verify it fails for the RIGHT reason (not syntax error, not import error)
  4. The failing test defines what you're about to implement

GREEN: Make It Pass

  1. Write MINIMAL code to make the test pass
  2. Don't over-engineer - just make it work
  3. Hardcoding is acceptable temporarily
  4. The goal is a passing test, not perfect code

REFACTOR: Clean Up

  1. Only refactor AFTER tests pass
  2. Remove duplication
  3. Improve naming
  4. Run tests after EACH refactor change
  5. If tests fail, undo the refactor

Rules

  • NEVER write implementation before tests
  • One test at a time - don't write all tests upfront
  • Keep tests focused and isolated
  • Each test should test ONE behavior
  • Use descriptive test names that explain the expected behavior

Testing Documentation

For test patterns, utilities, and conventions, reference:

Key points from project testing standards:

  • Tests are co-located with source files (e.g., Button.tsx + Button.test.tsx)
  • Use render from @/test (not @testing-library directly)
  • 80% coverage required

Integration with feature-dev

During Phase 5 (Implementation):

  1. Before writing any component/hook/util, write its test first
  2. Verify test fails (RED)
  3. Then implement the code
  4. Verify test passes (GREEN)
  5. Refactor if needed
  6. Repeat for next piece of functionality

Common Mistakes to Avoid

  1. Writing implementation first, then tests (defeats the purpose)
  2. Writing all tests before any implementation (too much upfront)
  3. Not running tests after each change
  4. Writing tests that don't fail initially
  5. Over-engineering during the GREEN phase