Problem: The use of shared resources, like the system properties, may result in flaky test outcomes in the case of more than one execution thread or parallel execution.

Solution: The synchronization control allows the test planner to organize executions, assuring that a test that writes to a shared resource will be executed isolated.

Comment From: cuspymd

How much time will it save when running the test in CONCURRENT mode?

Comment From: gvma

How much time will it save when running the test in CONCURRENT mode?

According to the JUnit 5 User Guide in https://junit.org/junit5/docs/current/user-guide/#writing-tests-parallel-execution, if not otherwise defined, the default dynamic configuration "computes the desired parallelism based on the number of available processors/cores". This way, we believe the execution time will be a fraction of the available cores and threads proportion. In order to avoid flaky test outcomes due to concurrent access to shared resources, we also added a failsafe annotation in the specific method declaration.

Comment From: snicoll

Thanks for the PR but there is no indication that this particular test is flaky. The argument you've made could be applied to many other tests and we prefer to act on it on a case-by-case basis when flakiness actually happens.

Comment From: sbrannen

Furthermore, we do not execute any of the tests in our test suite using JUnit Jupiter's parallel execution support.

If we execute tests in parallel, that is managed by the Gradle build, and consequently, the @Execution annotation from JUnit Jupiter has no effect on that.