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.
