RFR: 8338468: [TestBug] Convert controls tests to JUnit 5

[Andy Goryachev]

On Tue, 10 Sep 2024 22:40:35 GMT, Marius Hanl <mhanl at openjdk.org> wrote:

>> Converting control module tests to junit5.
>> 
>> Most of the changes are trivial, except for the following:
>> 
>> 1. assertEquals() and similar methods: the message can be confused with the expected argument (junit5 moved the message to the last position)
>> 2. parameterized tests: junit5 allows for parameterizing individual tests
>> 3. parameterized `@BeforeEach` and `@AfterEach`: (see discussion below)
>> 4. charts: the test hierarchy for charts mixed parameterized and non-parameterized kinds, necessitating more changes
>> 5. overridden parameterized tests (must be annotated with ` @ParameterizedTest @MethodSource`
>> 
>> ### Parameterized Class-Level Tests
>> 
>> junit5 does not support parameterized class-level tests yet (see https://github.com/junit-team/junit5/issues/878)
>> 
>> The workaround is to setup each test explicitly by calling the method that used to be annotated with `@Before` in each parameterized test method.  There might be another solutions (see, for example, https://stackoverflow.com/questions/62036724/how-to-parameterize-beforeeach-in-junit-5/69265907#69265907) but I thought explicit setup might be simpler to deploy.
>> 
>> To summarize:
>> - remove `@Before` from the setup method
>> - call the setup method from each parameterized method (adding parameters and replacing `@Test` with
>> 
>>   @ParameterizedTest
>>   @MethodSource("parameters")
>> 
>> where parameters() is a static method which supplies the parameters.  In the case when parameters have more than one element, the following code might be useful:
>> 
>> private static Stream<Arguments> parameters() {
>>     return Stream.of(
>>             Arguments.of("a", 1),
>>             Arguments.of("foo", 3)
>>     );
>> }
>> 
>> 
>> ### Migration Tricks
>> 
>> Here are the steps that might speed up the process:
>> 
>> 1. remove all the junit4 imports
>> 2. paste the following junit5 imports (below)
>> 3. fix the errors
>> 6. optimize imports via IDE (command-shift-O in Eclipse on macOS)
>> 7. after all is done, verify that there is no more junit4 names by running the command mentioned below
>> 
>> junit5 imports (in no particular order):
>> 
>> import org.junit.jupiter.api.AfterEach;
>> import org.junit.jupiter.api.BeforeEach;
>> import org.junit.jupiter.api.Test;
>> import org.junit.jupiter.api.Disabled;
>> import org.junit.jupiter.params.ParameterizedTest;
>> import org.junit.jupiter.params.provider.MethodSource;
>> import org.junit.jupiter.params.provider.Arguments;
>> import static org.junit.jupiter.api.Assertions.assertEqu...
>
> `@MethodSource`, `@ValueSource` or `@EnumSource` are the best replacements for parameterized tests. But whatever option you choose, it is a bit of refactoring involved indeed. I would suggest to do the parameterized tests in a new ticket, after converting the 'easy' cases to JUnit5 for that particular module/package. 
> 
> I can also help on that if desired since I also think this is a good idea and logical step for the future of our tests (and all tests that will be written in the future of course).

Thank you @Maran23 !

It's pretty surprising that junit people thought it will be a good idea to drop support for class-wide parameterized tests...

-------------

PR Comment: https://git.openjdk.org/jfx/pull/1561#issuecomment-2342317644