Regression Testing the Design

Locked reference outputs mean any change that moves a headline number is flagged and explained before it is accepted.

Guarding the numbers that matter

A regression test stores a known-good output and re-checks it after every change. If the number moves, the test fails, and the change cannot proceed until someone explains why the move is correct. This is how a frozen design point stays frozen in practice rather than in principle.

From unit tests to integrated regressions

Unit tests guard individual functions; regression tests guard end-to-end results. We keep reference cases whose outputs -- plasma current 9.86 MA, peak field 16.84 T, Q_sci 3.424 -- are pinned to tolerance. A refactor that leaves them unchanged is safe; one that shifts them is either a bug or a genuine design change that must go through change control.

Tolerances set in advance

Every regression test carries a tolerance chosen before the test is written, based on the expected numerical variation, not adjusted afterward to make a run pass. A failing regression is investigated, never silenced by loosening the bound -- loosening a tolerance to pass is a form of fudging, and it is treated as one.

Regression testing is what makes the frozen-design methodology enforceable. Without it, a design point is a claim about a moment; with it, the design point is a guarantee maintained continuously against the code that produces it. In effect, the regression suite is how a frozen number defends itself: it turns the freeze from a statement of intent into a condition the code must continuously satisfy or fail loudly.