Re: [DISCUSS] Moving to JUnit5

Posted by Chesnay Schepler-3 on Nov 30, 2020; 12:32pm
URL: http://deprecated-apache-flink-mailing-list-archive.368.s1.nabble.com/DISCUSS-Moving-to-JUnit5-tp46852p46883.html

I presume we cannot do the migration module-wise due to shared test
utilities that rely on JUnit interfaces?

On 11/30/2020 1:30 PM, Chesnay Schepler wrote:

> Is it feasible that 2 people can do the migration within a short
> time-frame (say, a week)?
> Must the migration of a test be done in one go, or can we for example
> first rename all the Before/After annotations and then to the rest?
> Are there any issues with other test dependencies (i.e., hamcrest,
> powermock (PowerMockRunner), mockito) that we should be aware of?
>
> I generally like the idea of using JUnit 5, but am wary of this
> migration dragging on for too long.
>
> On 11/27/2020 3:29 PM, Arvid Heise wrote:
>> Dear devs,
>>
>> I'd like to start a discussion to migrate to a higher JUnit version.
>>
>> The main motivations are:
>> - Making full use of Java 8 Lambdas for writing easier to read tests
>> and a
>> better performing way of composing failure messages.
>> - Improved test structures with nested and dynamic tests.
>> - Much better support for parameterized tests to avoid separating
>> parameterized and non-parameterized parts into different test classes.
>> - Composable dependencies and better hooks for advanced use cases
>> (TestLogger).
>> - Better exception verification
>> - More current infrastructure
>> - Better parallelizable
>>
>> Why now?
>> - JUnit5 is now mature enough to consider it for such a complex project
>> - We are porting more and more e2e tests to JUnit and it would be a
>> pity to
>> do all the work twice (okay some already has been done and would
>> result in
>> adjustments, but the sooner we migrate, the less needs to be touched
>> twice)
>>
>> Why JUnit5?
>> There are other interesting alternatives, such as TestNG. I'm happy
>> to hear
>> specific alternatives. For now, I'd like to focus on JUnit4 for an
>> easier
>> migration path.
>>
>> Please discuss if you would also be interested in moving onward. To get
>> some overview, I'd like to see some informal +1 for the options:
>>
>> [ ] Stick to JUnit4 for the time being
>> [ ] Move to JUnit5 (see migration path below)
>> [ ] Alternative idea + advantages over JUnit5 + some very rough
>> migration
>> path
>>
>> ---
>>
>> Migrating from JUnit4 to JUnit5 can be done in some steps, so that we
>> can
>> gradually move from JUnit4 to JUnit5.
>>
>> 0. (There is a way to use JUnit4 + 5 at the same time in a project -
>> you'd
>> use a specific JUnit4 runner to execute JUnit5. I'd like to skip this
>> step
>> as it would slow down migration significantly)
>> 1. Use JUnit5 with vintage runner. JUnit4 tests run mostly out of the
>> box.
>> The most important difference is that only 3 base rules are supported
>> and
>> the remainder needs to be migrated. Luckily, most of our rules derive
>> from
>> the supported ExternalResource. So in this step, we would need to
>> migrate
>> the rules.
>> 2. Implement new tests in JUnit5.
>> 3. Soft-migrate old tests in JUnit5. This is mostly a renaming of
>> annotation (@Before -> @BeforeEach, etc.). Adjust parameterized tests
>> (~400), replace rule usages (~670) with extensions, exception handling
>> (~1600 tests), and timeouts (~200). This can be done on a test class by
>> test class base and there is no hurry.
>> 4. Remove vintage runner, once most tests are migrated by doing a final
>> push for lesser used modules.
>>
>> Let me know what you think and I'm happy to answer all questions.
>>
>
>