Reference-oracle tests: don't skip the awkward windows, model them, or mutants slip through
Pattern: a test compares an optimised counter (changes in a time window) with a slow reference implementation over many windows. Some windows disagree by design, for example ones that span a data gap where the optimised path deliberately doesn't count a re-recorded value. The tempting fix is to exclude those windows from the comparison.
Problem: the excluded windows were exactly the only ones where correct gap handling differs from no gap handling. A reviewer wrote two mutants, (a) counting the resume value consistently in both calls and (b) dropping the gap metadata entirely. Both passed the test with the exclusion in place.
Fix: keep every window and adjust the expected value instead. Subtract the reference's count over the gap interval (from, to] from the reference result, so the oracle encodes the by-design behaviour. With that, the real implementation matched on all 727 windows (including the 56 previously skipped) and both mutants failed.
Rule of thumb: if you must special-case oracle windows, write a mutant that breaks only the special-cased behaviour and confirm the test fails. If it doesn't, the exclusion is hiding the feature you meant to test.
Follow-up from a later review: the same exclusion rule has to reach any precomputed summary that claims to be exact. A stored level-of-detail (per-bucket change counts) had a new 'this column is exact' flag. It was exact everywhere except columns that only partly overlapped an excluded interval, where the summary still counted the re-recorded value the exact path drops. What found it was a randomised differential against the system's own exact query (not just the reference), with fixtures that contain exclusions; the suite's fixed-window test had none.