> Parallel execution must be explicitly enabled. When enabled, JUnit uses a fork-join thread pool, so tests may run concurrently on different worker threads. Because these threads are reused, a ThreadLocal value left behind by one test could be visible to a later test that happens to run on the same thread.

I don't understand your comment. JUnit docs describe parallel execution as an experimental feature that still has gotchas that you need to be mindful to avoid. So you have a test framework designed with isolation in mind for a specific execution mode, but when you go out of your way to try another execution mode that is described as experimental then you can stumble upon very corner cases where isolation is not ensured. What point did you wanted to convey?

I disagree so hard with the notion that isolation is somehow done for you, that I don't even know how to begin arguing.

I'll admit to starting this confusion by reading what I thought would be written, not what was actually there. TFA does phrase it to my satisfaction that the test is isolated. I assumed when reading it that Kent thought he had isolation but did not. By analogies: a naive programmer does not perceive the existence of race conditions; a naive web app developer doesn't perceive the existence of CAP; a naive backend engineer thinks they have full ACID guarantees when they're only guaranteed READ_COMMITTED. I thought I was reading another writer just wishing isolation into existence through ignorance.

(So I accidentally straw-manned Kent's argument, but maybe that's not such a problem, because it seems you're OK with the straw man version?)

Anyway, maybe a question moves things forward.

JUnit's been around for decades. Every developer has had multicore dev machines for decades. Why would parallel execution not be the default, or a simple toggle that everyone would turn on immediately?