New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[SUREFIRE-2064] Allow all supported values of [parallel] option #517
Conversation
In this PR, I fixed issues with handling of the [parallel] option in the existing implementation. However, I've since noticed a few other issues with the existing implementation:
These deficiencies should be addressed to maintain the quality of the Surefire project. I'll switch this PR to "draft" mode and see what I can do about these issues. |
b744c49
to
86f5e28
Compare
I've completely re-implemented the TestNG740Configurator class. The new implementation...
I retained code from the existing implementation to load the ParallelMode enumeration, convert the specified option to its corresponding constant, and set the XmlSuite parallel mode setting. I added exception handling and conditional blocks to toughen it up. |
...refire-testng/src/main/java/org/apache/maven/surefire/testng/conf/TestNG740Configurator.java
Show resolved
Hide resolved
Fixes implementation of #339 |
@Tibor17 Here are my revisions to enable support for TestNG 7.4+ |
...refire-testng/src/main/java/org/apache/maven/surefire/testng/conf/TestNG740Configurator.java
Outdated
Show resolved
Hide resolved
...refire-testng/src/main/java/org/apache/maven/surefire/testng/conf/TestNG740Configurator.java
Outdated
Show resolved
Hide resolved
@sbabcoc |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
lgtm.
...refire-testng/src/main/java/org/apache/maven/surefire/testng/conf/TestNG740Configurator.java
Outdated
Show resolved
Hide resolved
FUTURE: As an alternative to the version-specific custom parsing currently employed by the Surefire plugin, it might be worth exploring the possibility of using TestNG's Parser class instead. This can be instantiated with any input stream, including a ByteArrayInputStream. This would transform all option processing to a version-agnostic conversion of Surefire configuration settings to corresponding TestNG XML format, instantiating a Parser, and calling the |
@sbabcoc |
@Tibor17 I find it astonishing that anyone still uses JUnit 3.8.2. I continue to support JUnit 4.13.2 because I still want my libraries to run on Java 1.7. (I actually use byte code generation via Byte Buddy to add test lifecycle hooks at runtime.) |
@sbabcoc |
I'll see what I can come up with. |
@sbabcoc The situation is as follows. |
43db898
to
d5e3b09
Compare
@Tibor17: The revisions in this PR have been squashed to a single commit. Thanks for all your efforts on this project! |
@slawekjaranowski Can you pls help me making a review as well? Pls participate. |
throw new TestSetFailedException( "Unsupported TestNG parallel setting: " | ||
+ parallel + " ( only METHODS or CLASSES supported )" ); | ||
// convert and apply [threadcount] setting | ||
suite.setThreadCount( Integer.parseInt( threadCount ) ); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Previously it was threadCountAsString == null ? 1 : ...
. What would happen if parallel=classes but the ThreadCount is not set? How is TestNG implemented? It has default value 1?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I found the default value in TestNG:
private int m_threadCount = 5;
We should use the same line as before, means suite.setThreadCount( threadCount == null ? 1 : parseInt( threadCount ) )
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If all supported versions of TestNG provide a default for this setting, it may be best to not inject a default here. Just let TestNG provide its own default value. That's how the new code for TestNG 7.4+ behaves. I don't know the history of the original code to understand why this was coded to inject a default value of 1. (What's the benefit of specifying parallel execution if the thread count is 1?)
If the default implementation is changed so that it behaves like the new override, this override can be removed.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This PR should not change the behavior. It should fix the value parallel=none
and other previously unknown values for the same parameter. Structural changes are welcome as they do not change the behavior.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I can remove the implementation that bypasses the override of TestNG's default thread count, but it's unclear why the original code behaves this way. As it's currently implemented, specifying any form of parallel execution without explicitly specifying thread count will result in sequential execution.
The documentation here indicates that the default is 5, which would be true if the implementation in Surefire didn't impose a default value of 1.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We should not change behavior in this PR. We are only aiming for the fix regarding configuration with the parameter parallel
.
Speaking apart of thie PR, I would say that 5
is a kind of Bulgarian value in IT. The other frameworks do not use arbitrary values like TestNG does. The surefire providers should behave similar and so the surefire-junit47
has fallback value 0
. The developer who wrote the documentation obviously had a problem with 5
. Not sure if TestNG would have a problem with 0
(main Thread) and if 1
is a singleton non-main Thread. Feel free to check it out.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@Tibor17 As you indicated, TestNG provides a default value of 5. As I pointed out, the Surefire documentation also specifies 5 as the default value. There is no potential for the thread count to have any value other than 5 unless an explicit assignment is made.
I'll remove the code that overrides the default implementation for the thread count parameter. I'll open another issue regarding the improper behavior of the existing implementation (forcing the thread count to 1 in the absence of an explicit assignment).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Override of [threadCount] implementation removed. New issue opened here: https://issues.apache.org/jira/browse/SUREFIRE-2075
d5e3b09
to
d30e429
Compare
@sbabcoc |
@sbabcoc Thx for contributing. |
This pull request revises the handling of the TestNG 7.4+ [parallel] option so that it accepts all valid values.
Following this checklist to help us incorporate your contribution quickly and easily:
for the change (usually before you start working on it). Trivial changes like typos do not
require a JIRA issue. Your pull request should address just this issue, without
pulling in other changes.
[SUREFIRE-XXX] - Fixes bug in ApproximateQuantiles
,where you replace
SUREFIRE-XXX
with the appropriate JIRA issue. Best practiceis to use the JIRA issue title in the pull request title and in the first line of the
commit message.
mvn clean install
to make sure basic checks pass. A more thorough check willbe performed on your pull request automatically.
mvn -Prun-its clean install
).If your pull request is about ~20 lines of code you don't need to sign an
Individual Contributor License Agreement if you are unsure
please ask on the developers list.
To make clear that you license your contribution under
the Apache License Version 2.0, January 2004
you have to acknowledge this by using the following check-box.
I hereby declare this contribution to be licenced under the Apache License Version 2.0, January 2004
In any other case, please file an Apache Individual Contributor License Agreement.