Red-Green-Refactor Methodology

You are following the RED-GREEN-REFACTOR cycle for test-driven development. This methodology ensures code is thoroughly tested and well-designed through iterative cycles.

Core Principle

Write a failing test BEFORE writing any production code.

This is not optional. Every new feature, bug fix, or behavior change starts with a test that demonstrates the requirement.

The Cycle

1. RED Phase - Write a Failing Test

Before writing any implementation:

1. •Understand the requirement - What specific behavior needs to exist?
2. •Write a test that asserts this behavior
3. •Run the test - It MUST fail (red)
4. •Verify the failure - Ensure it fails for the right reason, not due to syntax errors

The test should be:

• •Focused on ONE specific behavior
• •Named to describe what is being tested
• •Using clear assertions with meaningful error messages

Example test structure:
describe('calculateTotal', () => {
  it('should apply discount when total exceeds threshold', () => {
    // Arrange - set up test data
    // Act - call the function
    // Assert - verify the result
  });
});

2. GREEN Phase - Make the Test Pass

Write the MINIMUM code necessary to make the test pass:

1. •Focus on passing, not perfection
2. •Take the simplest path - Even hardcoding is acceptable initially
3. •Do not add features the test doesn't require
4. •Run the test - It MUST pass (green)

Guidelines:

• •If tempted to write more code than needed, STOP
• •The goal is a passing test, not elegant code
• •Ugly code is acceptable at this stage

3. REFACTOR Phase - Improve the Code

With a passing test as your safety net:

1. •Identify code smells - Duplication, long methods, unclear names
2. •Refactor incrementally - Small changes, run tests after each
3. •Maintain green - Tests must pass after every change
4. •Stop when clean - Don't over-engineer

Common refactorings:

• •Extract method/function
• •Rename for clarity
• •Remove duplication
• •Simplify conditionals

Workflow Commands

When implementing a feature or fix:

1. •Start with a test file - Create or update the test file first
2. •Write ONE failing test - Focus on the smallest testable unit
3. •Implement minimally - Just enough to pass
4. •Refactor if needed - Clean up while tests are green
5. •Repeat - Next test for next behavior

Decision Points

When to Write a New Test

• •Adding a new feature or behavior
• •Fixing a bug (test the bug first)
• •Changing existing behavior
• •Edge cases discovered during implementation

When NOT to Write a Test

• •Pure refactoring (existing tests cover it)
• •Non-functional changes (formatting, comments)
• •Third-party library behavior

Verification Checklist

Before considering work complete:

• • All new code has corresponding tests
• • Tests fail when the feature is removed
• • Tests pass consistently (not flaky)
• • Code has been refactored for clarity
• • No unnecessary code was added

Common Mistakes to Avoid

1. •Writing tests after code - Defeats the purpose of TDD
2. •Writing too many tests at once - One test at a time
3. •Making tests pass with hacks - The test should drive good design
4. •Skipping the refactor phase - Technical debt accumulates
5. •Testing implementation details - Test behavior, not internals

Integration with Other Skills

This skill works well with:

• •test-patterns: Provides patterns for structuring tests
• •anti-patterns: Helps avoid common testing mistakes
• •debugging/root-cause-analysis: When tests reveal unexpected failures