Re: Bumping junit jupiter to version 6

Okay, I'll proceed with the previously discussed proposal for alpha-1. If
creating junit6 turns out to be the wrong choice, I think we can adjust
course before we get to beta-1.

On Sun, Mar 29, 2026 at 7:29 AM Paul King <[email protected]> wrote:

> Hi folks,
>
> In the following PR, I bumped our own internal testing framework to JUnit
> 6:
>
> https://github.com/apache/groovy/pull/2412
>
> Bumping a dependency is typically a business-as-usual activity that
> wouldn't need to be mentioned in the mailing list. But there was a
> design choice that is worth discussing.
>
>  Our usage of JUnit 5 was two-fold. We use it for internal testing. We
> still have tests written for JUnit 3 & 4, but Eric has been doing some
> nice work migrating more of our tests to JUnit 5. Migrating to JUnit
> 6, after a few small wrinkles, went smoothly. We should note that the
> JUnit 3 & 4 runners are now deprecated in JUnit 6. So for some future
> Groovy version, we may want to deprecate support for JUnit 3/4 which
> would include things likeGroovyTestCase and so forth. I don't propose
> we do that just yet but we should keep an eye on jupiter evolution.
>
> The other usage of JUnit5 is in our runner in the groovy-test-junit5
> module. The runner lets you run JUnit 5 scripts standalone in the
> groovyConsole or on the command-line. There is a JUnit platform
> console launcher these days but it isn't as nice for Groovy
> developers. So I propose we keep the runner.
>
> The way we package groovy-test-junit5 is worth thinking about. As well
> as the runner, we reference all the needed jupiter implementation jars
> as dependencies. So users can simply depend on that module and get
> everything they need. Now, it seems a little strange to reference
> groovy-test-junit5 and bring in jupiter version 6. So, we could rename
> that module to junit6 or jupiter, keeping the old one around as
> deprecated for backwards compatibility.
>
> I initially thought renaming to groovy-test-jupiter would be the best
> approach since that might save us from doing more work when (and if)
> there is a JUnit 7. But, after going through the implementation steps
> involved, I now think groovy-test-junit6 would be best. That lets our
> users just jump from JUnit 5 to 6 by changing one Maven coordinate. I
> can also see a few features we can add that would enhance jupiter but
> they depend on specific jupiter versions, so it would make sense to
> place them in the respective version modules. There would be some
> duplication in the runner code between junit5 and junit6 modules but
> its only small and I propose we live with which will make eventually
> deprecating the junit5 stuff easier.
>
> So to summarise, I propose a `groovy-test-junit6` module to live
> alongside the `groovy-test-junit5` module but you'd only ever want one
> of them. The `groovy-test-junit5` module will become an optional
> module. I.e., not included in groovy-all and not included in the
> standard distribution. That is what is in the PR, so feel free to try
> it out.
>
> Any thoughts?
>
> Thanks, Paul.
>