-
Notifications
You must be signed in to change notification settings - Fork 4.6k
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
Add suite thread pool size testng option #29211
Add suite thread pool size testng option #29211
Conversation
Signed-off-by: sergey gotovsky <thomas56miller@gmail.com>
…ng-option # Conflicts: # subprojects/plugins/src/test/groovy/org/gradle/api/tasks/testing/testng/TestNGOptionsTest.groovy # subprojects/testing-jvm/src/integTest/groovy/org/gradle/testing/testng/AbstractTestNGVersionIntegrationTest.groovy # subprojects/testing-jvm/src/integTest/groovy/org/gradle/testing/testng/TestNGFailurePolicyIntegrationTest.groovy # subprojects/testing-jvm/src/main/java/org/gradle/api/internal/tasks/testing/testng/TestNGSpec.java # subprojects/testing-jvm/src/main/java/org/gradle/api/internal/tasks/testing/testng/TestNGTestClassProcessor.java # subprojects/testing-jvm/src/main/java/org/gradle/api/tasks/testing/testng/TestNGOptions.java
Signed-off-by: sergey gotovsky <thomas56miller@gmail.com>
This is consolidate how the location of the directory is handled between a PersistentCache and a SingleDepthFileAccessTracker. Signed-off-by: sergey gotovsky <thomas56miller@gmail.com>
Signed-off-by: sergey gotovsky <thomas56miller@gmail.com>
- replace `@IgnoreIf` by `@Requires` Signed-off-by: sergey gotovsky <thomas56miller@gmail.com>
Signed-off-by: sergey gotovsky <thomas56miller@gmail.com>
44e5f20
to
4616447
Compare
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.
Thank you for your contribution to Gradle!
This change looks reasonable and should be able to be accepted soon once the few flagged issues are addressed. Please let us know if you need any help.
...jvm/testing-jvm/src/test/groovy/org/gradle/api/tasks/testing/testng/TestNGOptionsTest.groovy
Show resolved
Hide resolved
platforms/jvm/testing-jvm/src/main/java/org/gradle/api/tasks/testing/testng/TestNGOptions.java
Show resolved
Hide resolved
JavaMethod.of(TestNG.class, Object.class, "setSuiteThreadPoolSize", Integer.class).invoke(testNg, suiteThreadPoolSize); | ||
} catch (NoSuchMethodException e) { | ||
if (suiteThreadPoolSize < 1) { | ||
throw new InvalidUserDataException("The version of TestNG used does not support setting thread pool size."); |
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 message is incorrect, it should say something about how a size < 1 is invalid.
Please add a test to verify this failure behavior as well.
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 agree, initially I misunderstood how it works. I've made the changes and tested them—it looks like it's what we need. Please take a look.
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.
So if we have a version of TestNG that doesn't include this method, but we call it (needlessly) to set the thread pool size to 1, we won't see an error? I don't think this is the behavior we want - we'd always want to see the error in the exception case here. Even if the method would have no effect, users should still be made to remove the call from their build script if their TestNG version doesn't support it.
This would be more in line with the behavior of the other methods here and wouldn't need a full integration test to demo using this.
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 understand your point. However, the main reason I did it this way is due to the logic of other methods presented in this class. Let's look at the setPreserveOrder method, for example. It also throws an exception only if there is an attempt to set a value different from the default (false by default), which does not affect the program's execution.
I tested this in a separate project with an older version of TestNG (5.12.1) - I set setPreserveOrder to true and received an exception, but when I set setPreserveOrder to false, there were no exception. This is why I rewrote this method to reflect the behavior of existing methods.
However, I am new here, so if I misunderstood something, please let me know what exactly.
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.
OK, I see. I was comparing to the setSuiteThreadPoolSize
method, which I thought might be more relevant due to it also affecting parallelism.
I think this is fine then. Can you please add an integration test that uses an older TestNG version and demonstrates this failure, and then I think this is ready to merge?
Something simple like TestNGGroupByInstancesNotSupportedIntegrationTest
might be a good example to copy.
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 apologize for the delay. I have added a test that checks for the exception in the older version of TestNG. Please take a look.
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.
No worries! Thank you for your contribution, and for following up.
This all looks great, I'm merging it now to get it added for Gradle 8.9.
…iteThreadPoolSize` validation Signed-off-by: sergey gotovsky <thomas56miller@gmail.com>
…thub.com/SergeyGotovskiy/gradle into add-suite-thread-pool-size-testng-option
📊 Changes by Platform: this PR is 93% new code See details
|
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.
Thank you very much for your time and the feedback on my PR.
I reviewed and tried to address your comments. Please check if it looks better now.
JavaMethod.of(TestNG.class, Object.class, "setSuiteThreadPoolSize", Integer.class).invoke(testNg, suiteThreadPoolSize); | ||
} catch (NoSuchMethodException e) { | ||
if (suiteThreadPoolSize < 1) { | ||
throw new InvalidUserDataException("The version of TestNG used does not support setting thread pool size."); |
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 agree, initially I misunderstood how it works. I've made the changes and tested them—it looks like it's what we need. Please take a look.
platforms/jvm/testing-jvm/src/main/java/org/gradle/api/tasks/testing/testng/TestNGOptions.java
Show resolved
Hide resolved
...jvm/testing-jvm/src/test/groovy/org/gradle/api/tasks/testing/testng/TestNGOptionsTest.groovy
Show resolved
Hide resolved
JavaMethod.of(TestNG.class, Object.class, "setSuiteThreadPoolSize", Integer.class).invoke(testNg, suiteThreadPoolSize); | ||
} catch (NoSuchMethodException e) { | ||
if (suiteThreadPoolSize < 1) { | ||
throw new InvalidUserDataException("The version of TestNG used does not support setting thread pool size."); |
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.
So if we have a version of TestNG that doesn't include this method, but we call it (needlessly) to set the thread pool size to 1, we won't see an error? I don't think this is the behavior we want - we'd always want to see the error in the exception case here. Even if the method would have no effect, users should still be made to remove the call from their build script if their TestNG version doesn't support it.
This would be more in line with the behavior of the other methods here and wouldn't need a full integration test to demo using this.
JavaMethod.of(TestNG.class, Object.class, "setSuiteThreadPoolSize", Integer.class).invoke(testNg, suiteThreadPoolSize); | ||
} catch (NoSuchMethodException e) { | ||
if (suiteThreadPoolSize < 1) { | ||
throw new InvalidUserDataException("The version of TestNG used does not support setting thread pool size."); |
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.
OK, I see. I was comparing to the setSuiteThreadPoolSize
method, which I thought might be more relevant due to it also affecting parallelism.
I think this is fine then. Can you please add an integration test that uses an older TestNG version and demonstrates this failure, and then I think this is ready to merge?
Something simple like TestNGGroupByInstancesNotSupportedIntegrationTest
might be a good example to copy.
Signed-off-by: sergey gotovsky <thomas56miller@gmail.com>
@bot-gradle test and merge |
WARN: Based on labels, this pull request addresses notable issue but no changes to release note found. |
Signed-off-by: sergey gotovsky thomas56miller@gmail.com
Fixes #20773
Context
TestNg have an option to run xml suites in parallel. It's very useful feature for project with big count tests stored in xml (with other params like parallel/threads-count/parameter/etc), but we still can't set up this option via gradle. In this pr I try to add this option.
Contributor Checklist
<subproject>/src/integTest
) to verify changes from a user perspective.<subproject>/src/test
) to verify logic../gradlew sanityCheck
../gradlew <changed-subproject>:quickTest
.Reviewing cheatsheet
Before merging the PR, comments starting with