testng: How to check the test case corresponding to the invocation-numbers value from testng-failed.xml?
TestNG Version
7.4.0
Expected behavior
The test that failed in the first run should be the one that is retried.
Actual behavior
Some other test is run in the retry using the testng-failed.xml file.
Is the issue reproducible on runner?
- Shell
- Maven
- [✓] Gradle
- Ant
- Eclipse
- IntelliJ
- NetBeans
Test case sample
I’m having a bunch of tests that I run in parallel with a dataproviderthreadcount of 10. I see that the test that fails in the first run is not the same as that run in a retry using the testng-failed.xml file that looks like below. I believe the invocation-numbers property value is used for retrying the failed tests. Since I observe the issue with a 100% replication rate, I’d first like to understand how to identify the test case corresponding to this value.
<suite thread-count="10" parallel="classes" name="Failed suite [Gradle suite]" verbose="0">
<test thread-count="10" parallel="classes" name="Gradle test(failed)" verbose="0">
<groups>
<run>
<include name="GROUP_1"/>
<include name="GROUP_2"/>
</run>
</groups>
<classes>
<class name="package.TestSample">
<methods>
<include name="beforeSuiteHook"/>
<include name="verifySomething" invocation-numbers="9"/>
<include name="beforeMethodHook"/>
<include name="afterSuiteHook"/>
</methods>
</class>
<!-- package.TestSample -->
</classes>
</test>
<!-- Gradle test(failed) -->
</suite>
<!-- Failed suite [Gradle suite] -->
About this issue
- Original URL
- State: closed
- Created 2 years ago
- Comments: 23 (12 by maintainers)
Yes.
There does not exist anything today. Which was why I shared a sample that shows you how to do it.
That was a file that I created manually for demonstration purposes. If you are generating the TestNG suite xml file wherein you would like to build the intelligence of a retry of the failed invocation counts, then you would need to ensure that you include these values as well. What I shared is not meant to be used as a “use as is solution” but something that you would need to work on and tweak. So please try it out and then raise any specific issues that you may have encountered.
If this has answered your question, please feel free to close this issue.
@juherr We are talking about across executions ( which means the state needs to be saved externally) since for every execution the size of the data set varies and so the invocation count changes as well.
If testNG can determine the size of the data provider in advance then maybe it would be able to pin itself against the exact invocation count. But since we also have a lazy loading data provider i am not sure how we would be able to determine the test data size in advance.
@akshayamaldhure
This basically is telling you that the data provider’s 10th iteration (it starts from zero) would need to be run again because it failed before. This is TRUE only when the
testng-failed.xmlgets generated the first time. If you re-run this and if this fails again, then the value would become0because this time the data provider was run ONLY with 1 set of data and that also failed.Well this is going to be a tricky one because you would need to build some custom logic. Here’s one way of doing this.
testng-failed.xmlbut with an extra parameter that lists the keys that failed.My interface
A testng suite xml file that you can generate should be like below