[
https://jira.codehaus.org/browse/SUREFIRE-749?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=353227#comment-353227
]
Andreas Gudian commented on SUREFIRE-749:
-----------------------------------------
I must agree with Kristian and Tibor here. Running parallel tests in different
isolated classloaders is IMHO something that would be counterproductive to what
the parallel execution within one JVM is to bring in. For real isolation
between concurrent tests, there are our fork options (forkCount, reuseForks).
However, that creates concurrency on test class level only and not on method
(@Test) level.
Personally, if I had that use case, I would just create an appropriate JUnit
runner implementation - which should actually be quite streight forward and not
that hard to do (taking for instance BlockJunit4ClassRunner as a starting
point).
So I'd also vote to close this as wont-fix.
> Parallel methods should run in separate classloaders
> ----------------------------------------------------
>
> Key: SUREFIRE-749
> URL: https://jira.codehaus.org/browse/SUREFIRE-749
> Project: Maven Surefire
> Issue Type: New Feature
> Components: Junit 4.7+ (parallel) support
> Affects Versions: 2.8.1
> Reporter: Gili
>
> When running in parallel-method or parallel-both mode, each @Test should run
> in its own ClassLoader. I'm running into a lot of problems involving the use
> of static variables in 3rd-party libraries. Here are two examples:
> 1. slf4j: http://bugzilla.slf4j.org/show_bug.cgi?id=176
> 2. guice: http://code.google.com/p/google-guice/issues/detail?id=635
> I believe running in isolated ClassLoaders would fix both problems and it
> makes a lot of sense from a test isolation point of view so we should do it
> anyway.
> I believe Surefire's forkMode is defined in terms of isolated JVMs instead of
> ClassLoaders. Furthermore, it only seems to support per-Class isolation
> instead of per-@Test isolation.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
