[
https://jira.codehaus.org/browse/SUREFIRE-1055?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=341205#comment-341205
]
Tibor Digana edited comment on SUREFIRE-1055 at 2/10/14 5:44 PM:
-----------------------------------------------------------------
@Chris
I have seen this issue as well.
Before the version 2.16 we have not proper parallelism. I implemented new
parallelism and tested.
Since the old parallelism was not properly enabled you could not see this issue.
Now you have feature with concurrent execution, and the issue you can see in
log should not be real because the test-methods are executed but their
invocation is not properly handled by the logs.
In order to prove these symptoms put a little code in every test method and
lunch mvn test again. This means print test-method name by an ordinal
System.out.println(...) in it. Make sure every name of the particular method is
unique in whole project. Then count them in your custom logs. Alternatively you
can initialize an atomic counter, e.g. AtomicInteger, in a singleton and print
post-increment value in every test-method. If you get deterministic number by
every test round, the methods are called as expected but not printed by the
plugin.
I guess you will have positive answer which means that the issue still exists.
was (Author: tibor17):
@Chris
I have seen this issue as well.
Before the version 2.16 we have not proper parallelism. I implemented this
parallelism and tested.
Since the old parallelism was not properly enabled you could not see this issue.
Now you have feature with concurrent execution, and the issue you can see in
log should not be real because the test-methods are executed but their
invocation is not properly handled by the logs.
In order to prove these symptoms put a little code in every test method and
lunch mvn test again. This means print test-method name by an ordinal
System.out.println(...) in it. Make sure every name of the particular method is
unique in whole project. Then count them in your custom logs. Alternatively you
can initialize an atomic counter, e.g. AtomicInteger, in a singleton and print
post-increment value in every test-method. If you get deterministic number by
every test round, the methods are called as expected but not printed by the
plugin.
I guess you will have positive answer which means that the issue still exists.
> Parallel JUnit does not run all test methods with parallel=classesAndMethods
> perCoreThreadCount=false useUnlimitedThreads=true and threadCountMethods
> specified
> ---------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: SUREFIRE-1055
> URL: https://jira.codehaus.org/browse/SUREFIRE-1055
> Project: Maven Surefire
> Issue Type: Bug
> Components: Junit 4.7+ (parallel) support, Maven Failsafe Plugin,
> Maven Surefire Plugin
> Affects Versions: 2.16
> Reporter: Chris Hansen
> Attachments: surefire-output.txt
>
>
> Some test methods are skipped at random with the below configuration. When
> test methods are skipped in this way, only one method in the class runs.
> Running tests repeatedly with no code change often yields a different number
> of tests with each run (e.g. see the attached surefire-output.txt). Tests
> that take longer to run are less likely to be affected. This affects version
> 2.16 of Surefire and Failsafe equally.
> Here is a simple test project which reproduces the issue:
> https://github.com/hansenc/SUREFIRE-1055
> It has a few simple test classes with a naming convention for how many test
> methods are in each class (e.g. Methods4Test has 4 test methods).
> {code:xml}
> <plugin>
> <groupId>org.apache.maven.plugins</groupId>
> <artifactId>maven-surefire-plugin</artifactId>
> <version>2.16</version>
> <configuration>
> <parallel>classesAndMethods</parallel>
> <perCoreThreadCount>false</perCoreThreadCount>
> <useUnlimitedThreads>true</useUnlimitedThreads>
> <threadCountMethods>3</threadCountMethods>
> </configuration>
> </plugin>
> {code}
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
