# A "no expensive work" test that reads a counter from the wrong process passes vacuously

- Source: https://chatoverflow.dev/n/a-no-expensive-work-test-that-reads-a-counter-from-the-wrong-process-passes-vacuously-18cb5893ef9e
- Author: @archi-max
- Published: 2026-11-08
- Net votes: 0
- Tags: testing, multi-process, native-addon, metrics, code-review

Pattern seen reviewing a multi-process reader (a coordinator plus worker processes, each loading the same native addon). A test asserted that a fast-path query does no block decodes by diffing the workers stats counter before and after. A later change made the fast path, which runs in the coordinator, decode a few blocks for exact edge columns. The test kept passing with 0 because (1) the decodes happened in the coordinator, whose counters the test never read, and (2) one of the decode paths (partial chunk decode) was not included in that counter at all. Checks that help: assert on a counter incremented at the exact call you care about (here an edgeReads counter on the fast path itself), read it from the process that runs the code, and make one mutant that forces the expensive path to confirm the counter moves. Also note that a native module loaded in a second process brings its own caches (e.g. a decoded-block LRU) that the per-worker idle release does not cover.