The regressions are coincidental — three failures in two months is within normal variance and the slow regression suite was not worth running, so the decision to disable was sound.

Disabling regression testing removed the early-warning mechanism for unrelated breakage; finding regressions late is orders of magnitude more expensive than running the suite.

The team should add more unit tests to the new feature itself — focused coverage on the new code would have prevented the cross-area regressions without needing the regression suite.

Regressions can only be found in production by real users; an automated regression suite cannot detect them because the team can’t anticipate which areas the feature would affect.

Test B — it pins down the exact implementation, which gives the most precise failure signal when the discount logic changes in any way.

Test A — it asserts at the spec boundary, so any implementation that gives premium customers a 10% discount keeps it green.

Both — they test the same business rule and are equally robust to refactoring; the only difference is which layer they target.

Neither — both will break under any refactoring of the discount module, because both test the same logic that refactoring would touch.

Unit test — mock the database and assert save_profile was called with the right arguments, since the unit is the smallest scope where the save logic lives.

Integration test — exercise the save endpoint against a real (or in-memory) database and assert that subsequent reads return the new values.

System test — open a real browser, click Save, reload the page, and assert the UI shows the new value end-to-end through every layer.

No test needed — the framework’s ORM handles persistence and is itself well-tested, so application code does not need an additional test.

Nothing — system tests are the most realistic, so concentrating coverage at the most realistic level produces the strongest assurance per release.

This is the inverted pyramid (ice-cream cone) — most coverage at the most expensive level. The fix is to push behavior down to unit tests and reserve system tests for critical flows.

The team needs to add more system tests so the slow ones become less of a bottleneck through parallelism, and 350 system tests would parallelize better than 250.

The team needs to remove all unit tests because they don’t reflect production behavior, and the existing 5 are creating false confidence that hides the production-realism gap.

White-box tests can intentionally exercise defensive branches, error paths, and edge cases that the spec doesn’t enumerate — these are real implementation risks the spec is silent about.

Coverage tools, which are white-box by nature, remain useful as navigational maps for finding code that hasn’t been exercised at all by the black-box suite.

Black-box tests cannot detect issues the spec is silent on (e.g. a race condition in a private cache); a white-box test that exercises the cache logic directly can surface them.

Property-based testing makes white-box testing obsolete — generating thousands of inputs around the spec gives the same coverage signal that white-box ever provided, but at the spec layer.

Increase CI parallelism so it finishes in 10 minutes, and fix the flake (replace real I/O with fakes, replace sleeps with observable-condition waits, isolate shared state).

Remove the gate — it’s slowing the team down and the bypasses prove the team has settled on a higher-throughput, lower-assurance equilibrium that fits their context better.

Lower the bar — require only 50% of CI checks to pass before merge, so the team can ship around the flaky checks without bypassing the entire gate.

Add automatic retries on every failing test so transient flake disappears from CI signal and the gate becomes practically green on every reasonable PR.