tdd

name	tdd
description	Red-Green-Refactor test-driven development workflow. Guides the agent through writing failing tests first, then implementing code to pass them, then refactoring while keeping tests green.

TDD Skill

When to use this Skill

Use this Skill when you are:

• Implementing a new feature using test-driven development
• Adding test coverage to existing untested code
• Refactoring code while maintaining correctness via tests
• Working on a project that requires TDD as part of its workflow

The Red-Green-Refactor Cycle

1. Red — Write a Failing Test

• Write the smallest test that expresses the next piece of desired behavior
• Run the test and confirm it fails for the expected reason
• The test should fail because the feature is not yet implemented, not because of a syntax or setup error
• Name the test to describe the behavior being tested, not the implementation

2. Green — Make the Test Pass

• Write the minimum code necessary to make the failing test pass
• Do not write more code than needed — just enough to turn the test green
• Avoid the temptation to implement the "full" solution
• Run all tests to verify nothing else broke

3. Refactor — Clean Up

• Now that tests are green, improve the code structure
• Remove duplication, clarify names, simplify logic
• Run all tests after each refactoring step to confirm they still pass
• Do not add new behavior during refactoring — that requires a new Red step

Guidelines

• One behavior per test: Each test should verify one specific aspect
• Fast feedback: Tests should run quickly; mock external dependencies if needed
• Descriptive names: Test names should read like specifications
• Test the interface, not the implementation: Tests should survive refactoring
• Commit after each Green step: Small, frequent commits with passing tests

Things to Avoid

• Writing multiple tests before implementing any code
• Writing implementation code before having a failing test
• Skipping the refactor step when tests pass
• Testing private implementation details instead of public behavior
• Writing tests so tightly coupled to implementation that any refactor breaks them