A much better model still is a mixture. * Use multiple processes, but multiple tests per process as well. * Randomly split and order the tests on every run, t

A much better model still is a mixture. * Use multiple processes, but multiple tests per process as well. * Randomly split and order the tests on every run, to encourage catching flakiness. Print the seed for this as part of the test results for reproducibility. * Tag your tests a lot (this is one place where, as many languages provide, "test classes" or other grouping is very useful). Smoke tests should run before all other tests, and all run in one process (though still in random order). Known long-running tests should be tagged to use a dedicated process and mostly start early (longest first), except that a few cores should be reserved to work through the fast tests so they can fail early. * If you need to kill a timed-out test even though other tests are still running in the same process - just kill the process anyway, and automatically run the other tests again. * Have the harness provide fixtures like "this is a temporary directory, you don't have to worry about clearing it on failure", so tests don't have to worry about cleaning up if killed. Actually, why not just randomly kill a few tests regardless? I wrote some more about tests here [1], but I'm not sure I'll update it any more because of Github's shitty 2FA-but-only-the-inconvenience-not-the-security requirement. [1]: https://gist.github.com/o11c/ef8f0886d5967dfebc3d https://gist.github.com/o11c/ef8f0886d5967dfebc3d