One JUnit 5 test calls System.setProperty, another reads that property, and a third changes the JVM default time zone with TimeZone.setDefault. Under parallel execution, how do you stop them corrupting each other, and what built-in keys does JUnit provide for cases like these?

## Why these particular resources are hard System properties, the default locale, the default time zone and the standard output stream are all *process-wide singletons*. There is exactly one of each per JVM and any test can change it for every other test running at that moment. Sequentially this is merely untidy — a test sets a property, uses it and clears it. Under parallel execution it is a race: another test reading the property while the first is between set and clear observes whatever the mutator left there. This category is worth recognising as a class rather than as individual bugs. The tell is any call of the form `X.setDefault(...)` or `System.setSomething(...)` in a test. ## The canonical keys `org.junit.jupiter.api.parallel.Resources` exists to solve the coordination problem. A lock key is an arbitrary string; JUnit never inspects what it refers to. Two tests are only serialised if their key strings are equal. So if one team writes `@ResourceLock("system-properties")` and another writes `@ResourceLock("sysprops")`, both tests believe they are protected and neither is. The constants provide a shared vocabulary for the JVM-wide resources that everyone eventually touches: - `Resources.SYSTEM_PROPERTIES` — anything reading or writing `System.getProperty`/`setProperty`/`clearProperty`. - `Resources.SYSTEM_OUT` and `Resources.SYSTEM_ERR` — tests that redirect or capture the standard streams. - `Resources.LOCALE` — `Locale.setDefault` and anything whose formatting depends on the default locale. - `Resources.TIME_ZONE` — `TimeZone.setDefault` and default-zone-dependent formatting or parsing. - `Resources.GLOBAL` — the key underlying whole-suite exclusivity; you normally express that intent with the dedicated isolation annotation rather than by naming this key. Because the constants live in JUnit itself, a library's tests and your tests interlock correctly without any agreement between the authors. That is the entire value proposition, and it is why using the constant is strictly better than a private literal even inside a single codebase. ## Applying it to the three tests - The **property writer** mutates, so `@ResourceLock(value = Resources.SYSTEM_PROPERTIES, mode = ResourceAccessMode.READ_WRITE)`. - The **property reader** only observes, so `@ResourceLock(value = Resources.SYSTEM_PROPERTIES, mode = ResourceAccessMode.READ)`. Several such readers can run together; none runs while the writer holds the exclusive lock. - The **time-zone test** mutates a *different* resource, so `@ResourceLock(value = Resources.TIME_ZONE, mode = ResourceAccessMode.READ_WRITE)`. Different key means no contention with the property tests — they keep running in parallel, which is exactly the granularity you want. A test that mutates two of them declares two locks; the annotation is repeatable. The lock is held for the annotated node including its `@BeforeEach` and `@AfterEach`, which is essential here: the set/clear pair usually lives in setup and teardown, and it is that whole window that must be exclusive. ## Keys for your own resources For application-level shared state — a fixed port, a config file, a singleton cache, a database table — invent keys, but centralise them: ```java public final class TestResources { public static final String PAYMENTS_DB = "db.payments"; public static final String WIREMOCK_PORT_8089 = "port.8089"; private TestResources() {} } ``` A constant is greppable and a typo becomes a compile error rather than a silently missing lock. Choose granularity deliberately: one key per genuinely independent resource. Too coarse and unrelated tests queue behind each other; too fine and two tests that really do collide use different keys and are not protected. ## Restore what you change Locking makes the mutation safe with respect to *concurrent* tests, but it does nothing about *later* ones. A test that sets the default time zone and never restores it leaves every subsequent test running in that zone. Always capture the previous value and restore it in a `finally` block or teardown — and note that with parallelism the failure this causes will look random, because which tests ran afterwards is no longer deterministic. ## The better fix Every lock on a JVM global is a workaround for production code that reads a global instead of receiving a dependency. If the code under test took a `Clock`, a `ZoneId`, a `Locale` or a configuration object as a parameter, the test would need no lock, would run fully in parallel, and would be clearer to read. Locking is the right answer when the global is imposed on you — a third-party library that reads `System.getProperty` at class-initialisation time, or code you cannot change yet. Say that in an interview: the strongest answer names the lock *and* the refactoring that would make it unnecessary.