8339513: [TestBug] Convert fxml tests to JUnit 5

[aghaisas]

This converts FXML module tests to junit5.

All changes are trivial API replacements from junit4 to junit5.
There are no parameterized tests in this module.

---

Progress

• Change must be properly reviewed (1 review required, with at least 1 Reviewer)
• Change must not contain extraneous whitespace
• Commit message must refer to an issue

Issue

• JDK-8339513: [TestBug] Convert fxml tests to JUnit 5 (Enhancement - P4)

Reviewers

• Kevin Rushforth (@kevinrushforth - Reviewer)
• Andy Goryachev (@andy-goryachev-oracle - Reviewer)
• Marius Hanl (@Maran23 - Committer)

Reviewing

Using git

Checkout this PR locally:
$ git fetch https://git.openjdk.org/jfx.git pull/1564/head:pull/1564
$ git checkout pull/1564

Update a local copy of the PR:
$ git checkout pull/1564
$ git pull https://git.openjdk.org/jfx.git pull/1564/head

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 1564

View PR using the GUI difftool:
$ git pr show -t 1564

Using diff file

Download this PR as a diff file:
https://git.openjdk.org/jfx/pull/1564.diff

Webrev

Link to Webrev Comment

[bridgekeeper]

👋 Welcome back aghaisas! A progress list of the required criteria for merging this PR into master will be added to the body of your pull request. There are additional pull request commands available for use with this pull request.

[openjdk]

@aghaisas This change now passes all automated pre-integration checks.

ℹ️ This project also has non-automated pre-integration requirements. Please see the file CONTRIBUTING.md for details.

After integration, the commit message for the final commit will be:

8339513: [TestBug] Convert fxml tests to JUnit 5

Reviewed-by: kcr, angorya, mhanl

You can use pull request commands such as /summary, /contributor and /issue to adjust it as needed.

At the time when this comment was updated there had been 2 new commits pushed to the master branch:

• 3e6a272: 8339550: Enable javac lint options for tests
• 4f1d42a: 8339517: Add --enable-native-access flag when running tests

Please see this link for an up-to-date comparison between the source branch of this pull request and the master branch.
As there are no conflicts, your changes will automatically be rebased on top of these commits when integrating. If you prefer to avoid this automatic rebasing, please check the documentation for the /integrate command for further details.

➡️ To integrate this PR with the above commit message to the master branch, type /integrate in a new comment.

[mlbridge]

Webrevs

• 01: Full - Incremental (e8ba9561)
• 00: Full (40556761)

[kevinrushforth]

All looks good. I presume you verified that there are no assertXxxx calls with a message string? I didn't see any, and the GHA build is green.

[andy-goryachev-oracle]

I might suggest fixing the formatting for readability.
This is minor, will re-approve if you decide to fix it.

[Maran23]

Looks good to me too, just some formatting is off (as Andy also noticed)

[aghaisas]

All looks good. I presume you verified that there are no assertXxxx calls with a message string? I didn't see any, and the GHA build is green.

Yes. There are no assertXxxx calls with a message string in these tests.

[andy-goryachev-oracle]

thank you

[andy-goryachev-oracle]

@kevinrushforth : assertXXX with strings will most certainly fail during the GHA run, unless the message is exactly the same as the expected or observed parameter, in which case it is probably ok...

[kevinrushforth]

@kevinrushforth : assertXXX with strings will most certainly fail during the GHA run, unless the message is exactly the same as the expected or observed parameter, in which case it is probably ok...

Indeed, that is what would almost certainly happen. There is a (completely contrived) case where it will render the assert useless. If the message string is identical to the "expected" string (in which case, why would you bother with a message string), like this:

    assertEquals("some expected string", "some expected string", actualValue);

then changing the above case to a JUnit 5 assertEquals will cause the test to always pass (the comparison will be done on the first two arguments and "actualValue" will be the message string). I admit that this is so artificial as to be not really worth worrying about.

[aghaisas]

/integrate

[openjdk]

Going to push as commit 5993c09.
Since your change was applied there have been 2 commits pushed to the master branch:

• 3e6a272: 8339550: Enable javac lint options for tests
• 4f1d42a: 8339517: Add --enable-native-access flag when running tests

Your commit was automatically rebased without conflicts.

[openjdk]

@aghaisas Pushed as commit 5993c09.

💡 You may see a message that your pull request was closed with unmerged commits. This can be safely ignored.