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. >
