RFR: 8273242: (test) Refactor to use TestNG for RuntimeTests ExecCommand tests
Lance Andersen
lancea at openjdk.java.net
Tue Sep 7 22:15:11 UTC 2021
On Wed, 1 Sep 2021 16:37:24 GMT, Roger Riggs <rriggs at openjdk.org> wrote:
> The ExecCommand test of Runtime.exec is difficult to maintain; the parallel arrays are hard to keep in sync.
> This cleanup converts to use TestNG DataProviders and other improvements.
Looks good Roger.
A couple trivial questions/suggestions below but feel free to ignore :-)
test/jdk/java/lang/RuntimeTests/exec/ExecCommand.java line 107:
> 105: private static void deleteOut(String path) {
> 106: try {
> 107: Files.delete(FileSystems.getDefault().getPath(path));
More of a curious question, is there a reason you couldn't use Files::deleteIfExists or Path.of() instead of FileSystems.getDefault....
test/jdk/java/lang/RuntimeTests/exec/ExecCommand.java line 199:
> 197: System.setSecurityManager(null);
> 198:
> 199: testCommandMode(command, "Ambiguous Unset", testFile, perModeExpected.get(0));
Any thought to creating a constant for the index value for perModeExpected.get(XX) for extra clarity?
-------------
Marked as reviewed by lancea (Reviewer).
PR: https://git.openjdk.java.net/jdk/pull/5335
More information about the core-libs-dev
mailing list