Hm interesting, although I've never come across the need for this. I think it arises in a fairly specific set of circumstances - You're running unit tests for

Hm interesting, although I've never come across the need for this. I think it arises in a fairly specific set of circumstances - You're running unit tests for a compiled language. Broken code may crash - You also need to start processes from the same process. In contrast, I basically never have unit test processes that themselves start processes. Instead all unit tests are a single process, and started with a shell script. The shell is responsible for waiting, and handles concurrency. Although I guess the third consideration is - the tests need to work on multiple platforms I can sorta see that, though I still think it's fairly niche, because I think that starting both processes and threads should be parameterized. Library code generally shouldn't start processes or threads -- that should be a policy that you pass in. --- I have come across cases where I'm specifically testing code that starts processes (a shell!), and you get orphans if either the test code or the tested code isn't quite correct. However I'm pretty sure the pattern in the OP would not be enough in those cases -- as mentioned, it requires some cooperation from children and parents. And BTW the general problem of containing adversarial processes is impossible in Unix, and would require Linux cgroups (mentioned in the articled). There's an inherent race between enumerating children and killing processes. A malicious process can always escape your attempts to kill its children. To be honest, what I started doing more is running tests in CI, so there is another layer of cleanup. I think the bottom line is that tests that start processes are very much special cases, and should be separate from most of your test suite.