On Wed, 2 Jan 2019 at 19:12, Felix Schumacher <[email protected]> wrote: > > > Am 01.01.19 um 21:40 schrieb sebb: > > On Sun, 30 Dec 2018 at 16:12, Felix Schumacher > > <[email protected]> wrote: > >> > >> Am 29.12.18 um 12:15 schrieb Philippe Mouawad: > >>> Hello Felix, > >>> I made a commit yesterday illustrating what I was proposing. > >>> Nightly builds passed but It may be too early to conclude. > >>> Does it look ok to you ? > >> I hadn't thought about that interface. It will probably lessen the > >> chance that we hit the bug in our setup, but it is still present for all > >> systems, that don't know about the semantic of that interface. > > Huh? > > > > I don't follow. > > > > What bug are you referring to? > > We still have the bug I described, in my previous mails, that the script > base might be set to null, when the test cases are ran concurrently. The > interface marker we are using now is used by our test runner, only.
OK, I see. There does not seem to be a standard way to flag JUnit tests that must be run sequentially. It looks like Maven Surefire can use @NotThreadSafe [1] but this does not seem to fully solve all such issues. Whilst the current solution works, it might perhaps be worth considering using the annotation instead of the JMeter-specific interface. [The standard JCIP annotations use Retention=Runtime which means the jar must be present at run-time. That would be a nuisance for the main JMeter code, but not really an issue for tests.] Until such time as JUnit fully supports serial running, I suspect the only way that works with all test runners would be to implement locking for the tests that need to run serially. This would be more complicated and would affect the parallelism, but would potentially allow for several different locks where the tests exercise un-related code. [1] http://maven.apache.org/surefire/maven-surefire-plugin/examples/fork-options-and-parallel-execution.html#Parallel_Test_Execution_and_Single_Thread_Execution > Felix <snip/>
