Restore testnames when using suites in suite.

[martinaldrin]

Fixes #2709.

Did you remember to?

• Add test case(s)
• Update CHANGES.txt
• Auto applied styling via ./gradlew autostyleApply

We encourage pull requests that:

• Add new features to TestNG (or)
• Fix bugs in TestNG

If your pull request involves fixing SonarQube issues then we would suggest that you please discuss this with the
TestNG-dev before you spend time working on it.

Note: For more information on contribution guidelines please make sure you refer our Contributing section for detailed set of steps.

[bj-9527]

Hi Martin,

I think you also need to add some info in changes.txt.

[martinaldrin]

Hi Martin,

I think you also need to add some info in changes.txt.

thanks, done

[martinaldrin]

@krmahadevan please review when you have time.
I also have a question, if I understand now Java 11 is mandatory for next release, or will it be possible deliver patches on 7.5?

[krmahadevan]

I haven't quite understood the scenario wherein this doesn't work. Can we please help add a unit test for this which explicitly tests out the fix (am guessing that there's no test right now for this which is why the build was passing even though this functionality was broken)

[martinaldrin]

I haven't quite understood the scenario wherein this doesn't work. Can we please help add a unit test for this which explicitly tests out the fix (am guessing that there's no test right now for this which is why the build was passing even though this functionality was broken)

The problem occurs when we defined suites in suites as below, then it requires the test names to exist in all subsuites, after the bug that was introduced in TestNg 7.5. but we define several testnames that can exist in any of the subsuites and only the matching tests should be exuecuted.

DOCTYPE suite SYSTEM "http://testng.org/testng-1.0.dtd" >
<suite name="testsuite">
    <suite-files>
        <suite-file path="./subsuite1.xml" />
        <suite-file path="./subsuite2.xml" />
        <suite-file path="./../startrestart/subsuite3.xml" />
    </suite-files>
</suite>

Regarding the unit test, I will try to add one, but I did not find any unit test for the class TestNg

[martinaldrin]

I haven't quite understood the scenario wherein this doesn't work. Can we please help add a unit test for this which explicitly tests out the fix (am guessing that there's no test right now for this which is why the build was passing even though this functionality was broken)

I added a unit test in JarFileUtilsTest.java, since I was able to reuse allot of code for a similar test.
I managed to reproduce the fault by adding back the old method.

[krmahadevan]

@martinaldrin - I dont see any assertions. Was that intentional ?

[martinaldrin]

Yes, The purpose of the test is to ensure that a exception is not thrown. I can not add any assert methods.
We just ensure that the method do not check suites in jarfiles here, because that is handled later in JarFileUtiles.
And JarFileUtiles already have unit tests to ensure that this is working as expected, the problem started to aggregate suites in the jarfile here without consider sub suites.

A very similar method exist in class: JarFileUtil method: testngXmlExistsInJar that take care of that part.

[juherr]

Thank for the change! 👍