Programically Loading TestNG Suite from JAR File Fails to Delete Temporary Copy of Suite File

[speedythesnail]

TestNG Version

7.6.1

Expected behavior

When programmatically running TestNG, TestNG should load a suite yaml / xml file from a JAR.

Actual behavior

TestNG JarFileUtils copies the file from the jar to a temporary path, after it loads the suite file it attempts to delete the file.

If JarFileUtils fails to delete the file, it throws a FileNotFoundException, no matter what the cause is. This is not the case on my machine, the file definitely exists where it was reported to have not existed.

Is the issue reproducible on runner?

• Shell
• Maven
• Gradle
• Ant
• Eclipse
• IntelliJ
• NetBeans
• PowerShell (java -jar ${JAR_FILE} ), Adoptium JDK 17.0.4.101

Test case sample

Spring Configuration to set up TestNG

@Configuration
@Slf4j
public class TestNGConfig {
    @Bean
    public TestNG testNG() throws URISyntaxException, IOException {
        TestNG testNG = new TestNG();

        setTestNGSuiteFile(testNG);
        setTestNGThreads(testNG);
        setTestNGParallelMode(testNG);

        return testNG;
    }
    private void setTestNGSuiteFileInJar(TestNG testNG, final URI testNGXmlUri) {
        // Get the location of the JAR file that this class is executed from, so we can get the
        // YAML / XML testng suite file and programmatically run it.
       // e.g. C:\testApplication.jar or /usr/local/bin/TestApplication.jar
        final String jarFileLocation = getJarFileLocation(testNGXmlUri);

        testNG.setXmlPathInJar("BOOT-INF/classes/testng.yaml");
        testNG.setTestJar(jarFileLocation);
    }
    // Other non-important methods exists but are redacted for brevity
    ......
}

Main TestNG run:

@Service
public class TestService {
    final TestNG testNG;

    public TestService(final TestNG testNG) {
        this.testNG = testNG;

        testNG.run();
    }
}

Resultant Exception:

 Caused by: java.io.FileNotFoundException: Failed to delete file: C:\Users\steve\AppData\Local\Temp\testngXmlPathInJar-17673113249698129403\BOOT-INF\classes\testng.yaml
        at org.testng.JarFileUtils.delete(JarFileUtils.java:112) ~[testng-7.6.1.jar!/:7.6.1]
        at org.testng.JarFileUtils.delete(JarFileUtils.java:110) ~[testng-7.6.1.jar!/:7.6.1]
        at org.testng.JarFileUtils.delete(JarFileUtils.java:110) ~[testng-7.6.1.jar!/:7.6.1]
        at org.testng.JarFileUtils.delete(JarFileUtils.java:110) ~[testng-7.6.1.jar!/:7.6.1]
        at org.testng.JarFileUtils.testngXmlExistsInJar(JarFileUtils.java:92) ~[testng-7.6.1.jar!/:7.6.1]
        at org.testng.JarFileUtils.extractSuitesFrom(JarFileUtils.java:52) ~[testng-7.6.1.jar!/:7.6.1]
        ... 38 common frames omitted

The file does exist though:

 PS> Get-Item -Path C:\Users\steve\AppData\Local\Temp\testngXmlPathInJar-17673113249698129403\BOOT-INF\classes\testng.yaml

Directory: C:\Users\steve\AppData\Local\Temp\testngXmlPathInJar-17673113249698129403\BOOT-INF\classes

Mode                 LastWriteTime         Length Name
----                 -------------         ------ ----
------         11/5/2022   9:23 PM            126 testng.yaml

I am currently opening a PR for this issue, this issue is submitted so I have a Github # to add to the CHANGES.txt file.

[krmahadevan]

@speedythesnail - I noticed that you have mentioned your JDK as JDK17. TestNG is still not officially certified with JDK17. So can you see if you are able to recreate this issue with JDK11 as well (Just to ensure that we are ruling out JDK flavors as the reason for the behaviour)

I say this because we do have unit tests for this implementation and haven't seen any exception from it so far.

[krmahadevan]

@speedythesnail - Did something go wrong at your end? You seem to have merged your PR into the master branch in your fork and it seems to have closed out this issue, which is NOT the case since the fix never landed in the TestNG master branch

[speedythesnail]

@speedythesnail - I noticed that you have mentioned your JDK as JDK17. TestNG is still not officially certified with JDK17. So can you see if you are able to recreate this issue with JDK11 as well (Just to ensure that we are ruling out JDK flavors as the reason for the behaviour)

I say this because we do have unit tests for this implementation and haven't seen any exception from it so far.

I also compiled and ran my application with OpenJDK 11 and encountered the same issue :(. I'm fairly sure it is probably Windows-specific, but I don't have my Linux box readily available to test out to see if this is a platform-specific issue.

[speedythesnail]

@speedythesnail - Did something go wrong at your end? You seem to have merged your PR into the master branch in your fork and it seems to have closed out this issue, which is NOT the case since the fix never landed in the TestNG master branch

Oh that is interesting, I just opened a PR to merge my master branch back into TestNG's.

I created a separate branch in my fork to work out of, I am surprised that it impacted this issue, though I certainly had no intentions of closing this.