Test gotchas

Traps met while writing Core tests. Add one when a flaky or misleading test cost real time.

Allocation tests (GC.GetAllocatedBytesForCurrentThread)

• The counter can jump by one allocation context (~8 KB) under parallel test load — seen as 8200 B where the same window normally reads 128 B (2026-09-25, ~2 in 25 build+test runs). Not reproducible in isolation or with an in-test GC-pressure thread. A budget below ~8 KB must measure several windows and take the quietest (AmbienceDirector_SteadyState…); a real per-event allocation shows in every window.
• foreach over an interface (IReadOnlyList<T>, IEnumerable<T>) boxes the enumerator — 32–40 B per loop. Hot paths index instead (CombatSystem.HitSphere, Overlaps). List<T> / arrays typed concretely are fine.
• Undrained buffers grow in doublings in headless tests (_sounds, notices, damage events cap at a max but grow to it first): one-off spikes of 0.5–1 KB mid-window are that, not a leak. Budget per tick over ≥ 1000 ticks or drain like the Desktop does.
• Tests run on Debug builds: Core code is never JIT-optimised there, so tiered compilation / escape analysis don't change what Core allocates.

Timing tests (Stopwatch)

• A build server or parallel tests can steal the CPU for one measurement: take the best of several runs (AudioSpeedTests.RealtimeFactor). A real slowdown lowers all of them (checked with a Thread.Sleep mutant).