Why nextest is process-per-test
I’m often asked why the Rust test runner I maintain, cargo-nextest, runs every test in a separate process. Here’s my best attempt at explaining the rationale behind it.
A key factor distinguishing nextest from cargo test is that nextest runs each test in a separate process. With nextest, the default execution model is now, and will always be, process-per-test. This document explains why.
The Rust ecosystem is now staggeringly large. There are millions of Rust developers and billions of lines of Rust code in production today. A key challenge with driving adoption of any new technology, like a new test runner, is coordination: everyone needs to agree on how to run and manage them.
Game theory offers a powerful framework to study these kinds of coordination problems. Consider this classic problem: if two people need to meet in London on a particular day but can’t coordinate the time and place, they’re likely to choose noon at Big Ben. This becomes what game theorists call a focal point, also known as a Schelling point—a natural default that everyone can assume without discussion.
The process-per-test model is powerful because it serves as the focal point, the Big Ben, of how to run tests. Just as everyone in London knows where the Great Clock of Westminster is, every operating system knows how to create and manage processes. Just as noon is a natural meeting time, processes form natural fault boundaries. The process-per-test model forms a universal protocol that everyone in the ecosystem can rely on without explicit coordination.
