I prefer per process over the alternatives. When you write code you have the choice to do per process, per thread, or sequential. The problem is that doing mu

I prefer per process over the alternatives. When you write code you have the choice to do per process, per thread, or sequential. The problem is that doing multiple tests in a shared space doesn't necessarily match the world in which this code is run. Per process testing allows you to design a test that matches the usage of your codebase. Per thread already constrains you. For example: we might elect to write a job as a process that runs on demand, and the library we use has a memory leak, but it can't be fixed in reasonable time. Since we write it as a process that gets restarted we manage to constrain the behavior. Doing multiple tests in multiple threads might not work here as there is a shared space that is retained and isn't representative of real world usage. Concurrency is a feature of your software that you need to code for. So if you have multiple things happening, then that should be part of your test harness. The test harness forcing you to think of it isn't always a desirable trait. That said, I have worked on a codebase where we discovered bugs because the tests were run in parallel, in a shared space.