If you use standard unittest discovery the third item might apply as well, though probably not to the same degree.
I don’t think unittest has any support for distribution so the xdist stuff is a no.
On the other hand you could use unit test as the API with Pytest as your test runner. Then you can also use xdist. And eventually migrate to the Pytest test api because it’s so much better.
[0]: https://coverage.readthedocs.io/en/7.8.0/changes.html#versio...
So, I'd run the tests under cProfile first.
Saying you got a 5-7% improvement from a single change, discovered using the profiler, that took understanding of the test suite and the domain to establish it was OK, and that actually changed the functionality under test - that's all an argument for doing exactly the opposite of what you recommend.
It was an old functionality. Someone wrote a super class that for the need of testing filesystem functionality created extremely large images. Not only there was no need to test with such large images, other developers eventually inherited more testcases from that setup code (because there were other utility methods), and now setUp code was needlessly creating images that no test used.
Generating a huge 4k image takes a significant time using Pillow.