[
https://jira.codehaus.org/browse/SUREFIRE-749?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=271170#comment-271170
]
Mark Struberg commented on SUREFIRE-749:
----------------------------------------
I fear this wont work out too.
Consider the following (pretty frequently used) scenario:
Your @BeforeClass starts a container (e.g. Weld, Spring or OpenWebBeans), the
@AfterClass shuts it down again. This would not work as expected if you split
the single tests in separate ClassLoaders.
Basically the whole test setup needs to be aware that the tests are being run
in parallel mode. I had this problem in a few projects where we use testng. In
this case it's not even guaranteed that all tests of a class are executed in
one go, thus we had to do reference counting to guarantee that the container
got shut down correctly.
> 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 is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
