JUnit 5 / AssertJ migration

Development
1

As you may know, I am working on modernizing the test code from JUnit 4 to JUnit 5 & AssertJ. Several projects are already migrated, but the biggest is operaton-engine and this still lies ahead.

There are several challenges to solve until finally the tests can be migrated. With the smaller projects OpenRewrite was already a huge help. However, migration to JUnit 5 is not straight forward. OpenRewrite can’t deal with complex concepts like Rule Chains and parametrized JU 4 tests. The code is broken and has to finalized by hand. This has been done for quite some modules already.

At the moment I am preparing the test code from operaton-engine step wise. And I am writing to inform you about an important step I’m going to take soon.

As said, OpenRewrite is offering recipes for migration of JUnit 4 to 5 and assertions to AssertJ. However, the latter only works on JU5 code ATM, and migrating to JU5 would damage too much right now. So I am preparing to migrate the JUnit 4 assertions directly to AssertJ code. Therefore I have enhanced the existing recipes to be able to handle JUnit 4 code also, and even provided a PR to OpenRewrite. However, it looks as if this PR won’t be merged, as the OR team does not want the resulting complexity of the recipes and JU4 is already that old.

Anyway, these recipes are working for us, and I am currently using them to migrate the test code base from operaton-engine. It still requires a bunch of manual rework, since there are ambiguities between AssertJ’s assertThat and own assertions with the same method name. But this is just work.

I am writing to prepare you that soon I will contribute these changes and it will be a huge change set. Fortunately, the test code base is really good and errors are likely detected. Anyway, I will thoroughly go through the changes.

There will be more preparing steps for the final migration coming. I plan to write OpenRewrite recipes for that purpose that. This to come later.

Have a great weekend!

Screenshot 380
Screenshot 3803314×578 199 KB

2

Hi Karsten,

thanks for all the effort you’re putting into this.

Looking forward to the day when we can say we have successfully completed the migration to Junit5.

This will make backporting a bit tougher because all tests need not only to be backported but also migrated to Junit5.

Do you think the Openrewrite Scripts could also help with backports?

Cheers,

Julian

3

Yes I know this is a hurdle. Open Rewrite won‘t help with it, this operates on compilable and schematic changes. And you would have to know which recipe to execute (could be a composite one though) and perform it on a large code base, which takes a bit time.

It is not a big problem, though. When new test code is added and it uses JU4 assertions it is still possible to use them, or when the JU4 dependency is removed, easily to convert.

Usually it is easier to just do the manual changes instead of running OR for small changes.

If you experience concrete problems with a backport, just provide the PR and ask for help to resolve potential conflicts.

4

The first clean up wave is finished. The initial migration raised hundreds of new Sonar findings. I have gone through everyone. And while I was on it, I have cleaned up most warnings. Again, 300 Sonar findings down and many other warnings that the IDE has showed me.
The engine test code is now much cleaner.

Next I will do the same for the rest of the code base.

2 Likes
5

My colleague Arne Deutsch started to migrate the tests of the engine module and is now incrementally providing PRs for chunks of tests. This is an important step forward in our challenge to migrate all tests. And finally I’m not alone with this burden :relieved:

1 Like