[
https://jira.codehaus.org/browse/SUREFIRE-749?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=271011#comment-271011
]
Kristian Rosenvold commented on SUREFIRE-749:
---------------------------------------------
Parallel methods are handled at the JUnit level and I do not think at least
JUnit provides the extensibility to control the classloading you are
requesting. You will have to file this issue against JUnit itself, or find out
if TestNG supports anything like it.
In your situation I think the easiest way forwards is probably to fix the two
issues you mention in slf4j and guice. I am not seeing surefire adding all
kinds of workarounds to handle bad singleton state handling in various other
frameworks. And from what I understand of the JUnit project you're not going to
see it come from there either.
You will also have to decide if you're doing this for /performance/ or because
you just need to test the stuff and the provided isolation levels are
suboptimal. We might be adding more forkmode options to surefire, but throwing
more forks at any problem never increases performance (it might solve your
singleton problems though ;). If you're looking for performance you're better
off fixing the bugs in guice/slf4j.
Unless you yourself come up with a well-tested patch that is reasonably clean,
I really don't see this issue as ever being fixed. I will be nominating this
issue as won't fix.
> Parallel methods should run in separate classloaders
> ----------------------------------------------------
>
> Key: SUREFIRE-749
> URL: https://jira.codehaus.org/browse/SUREFIRE-749
> Project: Maven Surefire
> Issue Type: Improvement
> 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 is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
