[
https://jira.codehaus.org/browse/SUREFIRE-749?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=353311#comment-353311
]
Andreas Gudian commented on SUREFIRE-749:
-----------------------------------------
> You didn't explain how one would implement this across the board for both
> JUnit and TestNG, and how one would subsequently integrate with Surefire.
I don't think it can be easily implemented for both JUnit and TestNG at the
same time. I could do it with my right hand tied behind my back for JUnit by
creating a new Runner in the user code (outside of surefire), which whould also
have the advantage that you can use it the same way when you don't run the
tests via Maven, but right inside any IDE (Eclipse and IntelliJ both have their
own launching code for tests).
For TestNG, that's not so easy, if even possible at all with their current API
- neither for the user code, nor for the launch code (e.g. in Surefire or in an
IDE). That's what I learned in my brief encounters with TestNG and that's also
what can be read in the google-groups link you posted above.
But as Tibor said: if you have a good idea on how to tackle the problem for
different test frameworks in Surefire, you're welcome to send in a pull-request
and we can discuss the approach.
> 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
> Assignee: Kristian Rosenvold
>
> 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)
