Migrate Spring Batch Integration to JUnit Jupiter

[hpoettker]

As of now, most of Spring Batch's tests are written with JUnit 4 which works mostly fine but lacks some niceties (e.g. parameterized tests are a bit cumbersome), and can lead to issues when integrating with test frameworks of other projects. 😉

This PR migrates the tests of Spring Batch Integration fully to JUnit 5 such that JUnit 4 is no longer on the classpath of the module.

The changes are optimized for reviewability in the sense that I tried to keep them minimal. E.g. all the public modifiers are still there as their removal would be very noisy.

The most part of the PR has been done by automation. Only AsyncItemProcessorMessagingGatewayTests and PollingAsyncItemProcessorMessagingGatewayTests were migrated manually for the most part.

Please let me know if you're interested in the same for the other modules.

[fmbenhassine]

This is awesome! Thank you for contributing this update, REALLY appreciated 👍

The changes are optimized for reviewability in the sense that I tried to keep them minimal. E.g. all the public modifiers are still there as their removal would be very noisy.

That noise is not issue for the review. If we decide to move to JUnit 5, let's do it in a clean way from the beginning. Please go ahead and apply all the best practices recommended by JUnit 5 in this PR (and others).

The most part of the PR has been done by automation.

Nice! Just curious, which automation tool have you used? We had an internal discussion about this kind of migrations and we were planning to use open-rewrite for it. We had a successful PoC by the team at moderne.io in #3945.

Please let me know if you're interested in the same for the other modules.

Yes please! a PR per module should work.

Please note that we are planning to review testing support in Spring Batch in 5.0.0-M5, so those PRs would be reviewed only when we start working on that milestone. Many thanks upfront.

[hpoettker]

Thanks for the detailed and encouraging feedback! I'm also quite intrigued by the promises of OpenRewrite and Spring Boot Migrator. This PR is basically a by-product of me having a look at them.

To explore the problem space and to create a baseline for a fair comparison, I approached the problem with sed commands, quick-and-dirty scripting, and manual finishing touches. That's what I euphemistically referred to as "automation". 😄

I set out with the expectation to give up at some point but got surprisingly far as the programming style is very consistent for a code base of this size and age. The only pain was the migration from expected exceptions at the @Test level to assertThrows around the specific throwing line. I didn't want to wrap the whole body of the functions and the heuristic that it's most likely the last line didn't really work out. But that's a problem that I don't expect automated tools to solve based on static code analysis.

I'll try out the fully automated solutions in the next days. It would be fun to discuss this kind of PR on the level of recipes to be selected. I'll keep you posted.

[hpoettker]

I've replaced the explicit catches of expected exceptions with assertThrows. Furthermore, I've removed unnecessary public modifiers and throws clauses, used static imports for assertions, and replaced the remaining explicit catching of expected exceptions.

I think the PR now has a nice scope for a JUnit 5 migration. Please let me know whether you agree or if you'd increase or decrease the scope.

Something that could be considered is a migration to AssertJ. But I think this PR would get unmanageable, if it were included here.

[hpoettker]

As 5.0.0-M4 has been released, I've squashed and rebased the latest state on the commit with the tag 5.0.0-M4.