Add a decorator to run a test in an isolated subprocess

[serhiy-storchaka]

Feature or enhancement

Some tests need to run in a fresh interpreter, isolated from the rest of the test run: they mutate process-global or interpreter state that would leak into (or be polluted by) other tests, depend on a clean interpreter startup, or may crash the interpreter outright. Today this has to be done ad hoc per test (spawning a child via script_helper, hand-rolling the result reporting), which is verbose and inconsistent.

I propose a decorator that runs a test in a dedicated subprocess and reports the result transparently, so the test reads like any other:

class MyTest(unittest.TestCase):
    @isolated()
    def test_global_state(self):
        ...

It would start in test.support and could later move to unittest.

Proposed behaviour

• @isolated() decorates a test method (only that method runs in a subprocess) or a whole TestCase subclass (the whole class runs in a single subprocess, so setUpClass()/setUpModule() run once there).
• Failures, errors and skips — including those of individual subTest()s — are reported for the corresponding test, and show the original subprocess traceback.
• A setUpClass()/setUpModule() failure or skip in the subprocess is reported for the whole class.
• The subprocess inherits the parent's regrtest configuration (enabled resources -u, memory limit -M, verbosity -v, failfast), so requires_resource(), requires(), bigmemtest() and similar behave the same in both processes.
• A running_isolated flag is true while running in the subprocess, so setUp()/tearDown() and the class- and module-level fixtures can choose what to run there.

Linked PRs

Linked PRs

• gh-152548: Add a test.support.isolated() decorator #152551
• gh-152548: Convert test_audit to the test.support.isolated() decorator #152565
• gh-152548: Convert test_eintr to the test.support.isolated() decorator #152570
• gh-152548: Convert the test_signal wakeup tests to @isolated() #152639