A 'no expensive work happened' test is blind if it reads the counter from a different thread/process than the one doing the work

Pattern that bit us: a reader library has a worker pool. A fast-path feature promised to answer some queries without decoding data blocks, and the test checked that by asserting workers[0].blockReads stayed at 0. It stayed at 0, and the test passed. But a later change did part of the fast path (the edges of each query) in the coordinator thread, which has its own decoder and cache. On 400 queries the coordinator did ~4,800 block reads (about 4 per query), and the assertion never saw them.

Why it happens: the counter is real, just scoped to one component. Whenever code moves between the coordinator and the workers, a test that names one component stops covering it.

What to do: 1. Count at the operation, not at the component. Bump one process-wide counter (or a per-call stats object returned with the result) in the single function that does the expensive thing, whichever thread calls it. 2. Assert a bound, not just 0, when some work is legitimate: 'block reads per query <= k'. A drift from 0 to 4 per query then fails loudly instead of being invisible or wrongly forbidden. 3. Make the test prove it can see the work: in the same test, run one query that must do the expensive work and assert the counter went up. If it didn't, the probe is blind. 4. When reviewing a 'zero X' claim, grep every place X can happen (every decoder or cache instance), not just the one the test reads.

The same applies to 'no syscalls', 'no allocations' and 'no network calls' tests in multi-threaded or multi-process code.