Naming a failure in a test does not establish that execution reached it. An early exit or invalid setup can prevent the intended race altogether. Earlier I covered reservation leases. Here I focus on test design that demonstrates where a fault actually occurred before counting its result.
Failing any write would answer a different question
To test failure of the running-state write, the save substitute fails specifically when status is running. Failing creation or initial-list storage would not exercise lease cleanup immediately before dispatch. The existing test names the status and occurrence and checks that execution calls remain zero.
A final-write test first records the run identity and then fails subsequent writes. The same storage error before and after delivery has different replay implications. I read the injection predicate and previously completed stages beside the error code. Fixing the location explains why a later tick must not increase the dispatch count.
Use a gate rather than guess the timing
Cancellation races use entered/hold promises. One case holds a cancellation write before starting tick; the other holds the running write before requesting cancellation. A single sleep where whichever side happens to be faster wins cannot replace both cases.
Cancel-first requires zero dispatch and retained cancelled state. Run-first requires cancellation refusal and preserved success. Progress in another project is asserted separately. The test does not explore every thread or power-loss ordering. It deliberately constructs two named transition orders, which is a precise and useful verification scope.
After shutdown, inspect what delayed preparation did not create
NotebookService tests hold Python-environment preparation or initial notebook loading, issue shutdown, release the gate, then await both run and shutdown. Assertions check busy false, no kernel and a retained stopped message.
The test checks whether preparation that finishes after shutdown refrains from spawning a new process. That lifecycle gap can be examined without a model or external service. The executable path is a fixture value; the test does not terminate the user's Python environment. Evidence should name the resource that was expected not to appear.
After copy failure, inspect the peer and restart too
An owned Electron copy fixture points its database at a missing work folder and asserts an actual ENOENT. It compares project/tab lists, source draft and peer project against the before state. Absence of an incomplete visible project is only one of its checks.
It also verifies the peer's actual Python output continues and that a normal restart does not reveal an incomplete copy. Restoring the missing folder permits a later copy attempt from the same source. That is new evidence under changed conditions, not conversion of the old failure into success. Distinguish a substituted write failure from an actual missing fixture path.
Expose reachability in the synthetic experiment as well
The shared lab separates fault_requested from fault_exercised. A requested final-record error remains unexercised if earlier cancellation prevents reaching it. Send count, read evidence and final recording can be inspected together, but they certify neither disk durability nor actual browser behavior.
For this article I read original tests and executed only the independent synthetic module, injecting no fault into the operational app. Keeping cleanup, peer progress and non-replay as separate questions makes each claim assessable. Verification should establish that the intended failure occurred and describe the state afterward, rather than accumulate only normal-path successes. A test that exits before its fault predicate needs a different conclusion: the planned experiment remains unperformed, even if its cleanup assertions pass.