Regression Tests Guard What Already Worked

A bug fix can solve one failure and create another.

That is why debugging is not complete when the formerly failing input passes.

Preserve the original defect as a future test

Suppose Version 1 had:

if (score > 90) return "HIGH";

Score 90 incorrectly produced PASS.

After fixing the condition to >= 90, keep the case:

score 90 -> HIGH

That becomes a regression test. If a later refactor reintroduces the boundary defect, the test catches it.

Fix local, test wider

A practical loop:

reproduce failure
      |
identify responsible boundary
      |
make controlled change
      |
rerun failing case
      |
rerun nearby + previously passing cases

The wider cases are not random. Choose behavior that the changed code could plausibly affect.

Example: parsing fix

Version 1 rejects text with outer spaces:

" 42 "

Version 2 trims before parsing.

Regression set should include:

• "42" still works;
• " 42 " now works if requirement allows trimming;
• "4 2" still fails;
• "abc" still fails;
• boundary numeric values still follow domain rules.

A fix that turns every parse failure into 0 might make the new case pass while silently breaking invalid-input behavior.

Tests are a safety net for refactoring

Unit 16 will change program structure without intentionally changing behavior.

Before refactoring, capture the required behavior in tests. After refactoring, run the same tests.

Green regression tests do not prove the design became better. They provide evidence that required external behavior stayed stable while internal structure changed.

Avoid testing private implementation details

If a test fails merely because you renamed a private helper while public behavior stayed correct, the test may be coupled to implementation rather than contract.

Prefer tests through meaningful public behavior when possible.

There are exceptions in complex systems, but the beginner principle is strong: tests should protect what users/callers need, not freeze every internal line.

Build a regression story

Choose one real defect from Units 1-14.

Create:

Version 1 failing behavior
root cause
new test case that reproduces it
Version 2 correction
failing case now passing
three regression cases still passing

If you have JUnit, encode the set there. Otherwise use the browser harness.

Evidence

Explain why each regression case belongs in the set. "To have more tests" is not a justification.

Connect each case to a boundary, requirement, or behavior that the correction could have disturbed.