regression-testing

Regression Testing

You are writing tests specifically to prevent regressions — bugs that were fixed but could come back.

Process

1. Identify Regression Risks

High-risk areas for regressions:

• Code that was recently fixed (the fix might be incomplete)
• Code that's frequently modified (high churn = high risk)
• Code with complex conditional logic (many branches = many ways to break)
• Code at integration boundaries (where two systems meet)
• Code without any existing tests

2. Write Characterization Tests

Before changing any code, capture current behavior:

// Characterization test: documents current behavior
// If this test breaks during refactoring, you changed behavior (intentionally or not)
it('should return empty array when no items match filter', () => {
  const result = filterItems([], { status: 'active' });
  expect(result).toEqual([]);
});

3. Write Regression Tests for Fixed Bugs

Every bug fix needs a regression test:

// Regression: https://github.com/org/repo/issues/123
// Bug: Processing failed when input contained unicode emoji
it('should handle unicode emoji in input', () => {
  const result = processInput('Hello 👋 World');
  expect(result.text).toBe('Hello 👋 World');
});

Rules for regression tests:

• Reference the original issue/bug in a comment
• Test the exact scenario that triggered the bug
• Test close variants (if emoji broke it, test other unicode too)
• Place near related tests, not in a separate "regression" file

4. Coverage-Guided Test Writing

Find untested code paths:

# Generate coverage report
pnpm test --coverage

# Look for:
# - Uncovered branches (if/else paths never hit)
# - Uncovered functions (dead code or missing tests?)
# - Low-coverage files (< 60% line coverage)

Prioritize coverage for:

1. Public API functions (users depend on these)
2. Error handling paths (failures should be predictable)
3. Edge cases in business logic
4. Data validation and transformation