JUnit 6 was released, and at some point we should discuss what to make of it: JUnit Release Notes
There are some questions which come to mind for me:
What do we have to do to enable Operaton users to test their apps with JUnit 6?
When will we port Operatons own test suite to JUnit 6?
The first question could be solved by an experiment / development spike: Creating an application which uses Operaton and runs JUnit 6 as a test suite. This is not crucial, but should not be low priority, too, because it might restrict our users to a certain technology stack. There are already projects that report their JUnit 5 extensions as compatible with version 6: JUnit 6 is here, what does it mean for Vert.x users? | Blog | Eclipse Vert.x but there are some breaking changes, so this compatibility is not a given. If two or three people here agree to explore this, we should create an issue in GitHub, e.g. “Ensure JUnit 6 compatibility of the Operaton JUnit Extensions”
The second question depends on the time and effort needed and available to the project, really. Do you see any roadblocks, any problems or open questions? This is not important / pressing at all, and there is no need for us to rush.
What do you think? Do you already have experience with JUnit 6?
I do not have experience with JUnit 6 so far. Operaton is great to explore this.
For Operaton users I think we should provide “junit6” classified artifacts like those for JUnit 5. Likely there will be redundancy to JUnit 5 test extensions. Not sure if we shall try to make the existing infrastructure compatible to both, or copy/inherit. I would also not really like if users that want to write JUnit 6 based tests would have a dependency with classifier junit5.
I agree, the junit-5 classifier might be confusing, even if our existing extensions worked out of the box. An additional classifier would match the existing pattern quite well.
As part of my Spring 7 /Jakarta EE11 POC I simply changed the version to 6.0.1 in parent/pom.xml. All test incl. integration tests are running just fine. I did not need to change a single line of code related to Junit6.
Migrating from JUnit 5.x.y to 6.0.0 should be much easier than migrating from 4.x to 5.x. Only APIs that have been deprecated for over two years have been removed. All other APIs continue to be supported, making version 6.0.0 a drop-in replacement in most cases.
Because of this I would simply change the version. Note sure about the maven modul names and classifiers so. Introducing a junit6 variant seems overkill, but the naming is not optimal.
This is great news! Our effort investing into the test infrastructure pays here off.
Regading the naming: We could change the classifier to “junit-jupiter”. It is kind of a breaking change then, but we could provide an OpenRewrite recipe for it. Since it is just a dependency renaming I would not consider this requiring a major dependency version change.
When we would would change to the classifier “junit-jupiter” this would be breaking. But along with an OpenRewrite recipe we could change this. We should anyway have a set of recipes for upgrading Operaton, or avoiding usage of deprecated API, cleanups etc.