Refactoring

Refactoring is the third step of TDD. After GREEN, assess if refactoring adds value.

When to Refactor

• •Always assess after green
• •Only refactor if it improves the code
• •Commit working code BEFORE refactoring (critical safety net)

Commit Before Refactoring - WHY

Having a working baseline before refactoring:

• •Allows reverting if refactoring breaks things
• •Provides safety net for experimentation
• •Makes refactoring less risky
• •Shows clear separation in git history

Workflow:

1. •GREEN: Tests pass
2. •COMMIT: Save working code
3. •REFACTOR: Improve structure
4. •COMMIT: Save refactored code

Priority Classification

DRY = Knowledge, Not Code

Abstract when:

• •Same business concept (semantic meaning)
• •Would change together if requirements change
• •Obvious why grouped together

Keep separate when:

• •Different concepts that look similar (structural)
• •Would evolve independently
• •Coupling would be confusing

Example Assessment

// After GREEN:
const processOrder = (order: Order): ProcessedOrder => {
  const itemsTotal = order.items.reduce((sum, item) => sum + item.price, 0);
  const shipping = itemsTotal > 50 ? 0 : 5.99;
  return { ...order, total: itemsTotal + shipping, shippingCost: shipping };
};

// ASSESSMENT:
// ⚠️ High: Magic numbers 50, 5.99 → extract constants
// ✅ Skip: Structure is clear enough
// DECISION: Extract constants only

Speculative Code is a TDD Violation

If code isn't driven by a failing test, don't write it.

Key lesson: Every line must have a test that demanded its existence.

❌ Speculative code examples:

• •"Just in case" logic
• •Features not yet needed
• •Code written "for future flexibility"
• •Untested error handling paths

What to do: Delete speculative code. Add behavior tests instead.

When NOT to Refactor

Don't refactor when:

• •❌ Code works correctly (no bug to fix)
• •❌ No test demands the change (speculative refactoring)
• •❌ Would change behavior (that's a feature, not refactoring)
• •❌ Premature optimization
• •❌ Code is "good enough" for current phase

Remember: Refactoring should improve code structure without changing behavior.

Commit Messages for Refactoring

refactor: extract scenario validation logic
refactor: simplify error handling flow
refactor: rename ambiguous parameter names

Format: refactor: <what was changed>

Note: Refactoring commits should NOT be mixed with feature commits.

Refactoring Checklist

• • All tests pass without modification
• • No new public APIs added
• • Code more readable than before
• • Committed separately from features
• • Committed BEFORE refactoring (safety net)
• • No speculative code added
• • Behavior unchanged (tests prove this)