Version 2 Needs Regression Evidence, Not Relief

A previously failing test turning green is necessary. It is not sufficient.

The correction touched some part of the system. Determine what behavior could plausibly be affected and rerun those cases.

Build the regression set

Include:

1. the original failing case;
2. nearby boundary cases;
3. previously passing normal cases through the changed component;
4. at least one integration case crossing the changed boundary;
5. invalid-input behavior if validation or parsing changed.

Example: if you changed score threshold logic around 90, rerun 89, 90, 91, lower invalid, upper invalid, and an ordinary middle value.

Compare Version 1 and Version 2

Create:

A Version 2 where unrelated cases now fail is not a complete fix.

If requirements changed, say so

Sometimes investigation reveals that the original requirement was ambiguous or wrong.

Do not silently rewrite expected output until the test passes.

Record:

requirement revision:
why it changed:
who/what evidence authorized the change:
tests updated:
implementation updated:

For a classroom capstone, you are the designer, but the revision still needs a reason tied to the stated audience/problem.

Retest the architecture decision

If your change introduced a new implementation or collaborator, verify that existing callers still depend on the intended interface and that no new concrete-type branching leaked into the coordinator.

If your change altered a collection, retest duplicate/order/key semantics.

If your change altered parsing, retest malformed and domain-invalid data.

The regression set should follow the risk of the change.

Remaining limitations are allowed

A final project does not need infinite scope.

Write limitations honestly:

- browser core does not perform real filesystem I/O
- supports one input format only
- no persistence between runs
- no concurrency
- assumes dataset fits memory

Do not hide a missing requirement as a limitation. A limitation is a bounded capability outside or below the accepted scope.

Evidence

Submit the Version 1/Version 2 comparison table, regression result, and remaining limitations.

Then answer: What evidence would you need before trusting this program in a higher-stakes environment?

That question keeps a classroom demo from turning into an unsupported production claim.