Upgrade to JUnit 6

[gsmet]

• Update to JUnit 6
• Rename all quarkus-junit5* artifacts to quarkus-junit-jupiter* to avoid confusion and be consistent with JUnit naming
• Put relocations in place
• Some update recipes are prepared here: Update quarkus-junit5 dependencies to quarkus-junit-jupiter* quarkus-updates#410

Note that the assumption in this work is that junit-jupiter will mostly stay compatible and that they won't break everything. But I think it's a relatively fair assumption given how they handled the JUnit 4 -> JUnit 5 and the JUnit 5 -> JUnit 6 move.

[gastaldi]

@gsmet this is what I came up with my investigation back then: 8781c2c (#50355)

Note that you also need to bump devtools/gradle/gradle/libs.versions.toml

[gsmet]

@gastaldi ah sorry, I totally missed you had started this work.

[gsmet]

/cc @cescoffier @geoand @Sanne @aloubyansky @gastaldi please check the approach described in the description as the renaming is a rather massive change and I would like to be sure we're all on the same page.

See https://groups.google.com/g/quarkus-dev/c/yUc9s5U4DbA

[gsmet]

Also /cc @holly-cummins @mkouba as you were involved in some of the testing infra.

[geoand]

That's the plan I was +1 with :)

[github-actions]

🎊 PR Preview 5b8ebed has been successfully built and deployed to https://quarkus-pr-main-51412-preview.surge.sh/version/main/guides/

• Images of blog posts older than 3 months are not available.
• Newsletters older than 3 months are not available.

[Sanne]

I'm ok with this approach - but I wonder if you considered the alternative of introducing a new set of quarkus-junit6 artifacts rather than renaming?
That would give people an easier path to upgrade decoupled from other changes, but I'm guessing this is only relevant if the assumption of super-smooth migration proves too optimistic.

This could also be useful if we had some semantic changes on our wishlist which we didn't dare do because of user update hassle.

(But I fully agree this is all unnecessary if it's a very simple drop-in change)

[mkouba]

I understand that JUnit6 is more like an evolution with minimal breaking changes and as such a good candidate for drop-in replacement. And the user has an option to go back to JUnit5 and it should work, more or less.

But I wonder if we should clarify the strategy for future releases. quarkus-junit-jupiter suggests that we will support a single version of JUnit which might be compatible with other versions (i.e. JUnit6 and JUnit5). But it does not suggest which version/s is/are actually supported. And that's probably fine but it requires some extra knowledge.

Also I don't have any numbers but I think that most users do not care about platform/jupiter/vintage, so quarkus-junit might be a better choice for the artifactId. Or maybe even quarkus-test?

Another question is - what if JUnit7 will be a "revolution", i.e. not a drop-in replacement? The artifactId remains the same, but Quarkus will silently drop support for older versions of JUnit?

[aloubyansky]

Should this property be defined in the parent POM?

[aloubyansky]

Do we know what causes these changes?

[holly-cummins]

Hmm, yes, that looks like it might need investigation.

[gsmet]

It's expected, the order in which nested tests are executed have been changed and is now more natural.

[aloubyansky]

But I wonder if we should clarify the strategy for future releases. quarkus-junit-jupiter suggests that we will support a single version of JUnit which might be compatible with other versions (i.e. JUnit6 and JUnit5). But it does not suggest which version/s is/are actually supported. And that's probably fine but it requires some extra knowledge.

That's true. OTOH, the same could be said about Quarkus extensions, such as quarkus-hibernate.

Also I don't have any numbers but I think that most users do not care about platform/jupiter/vintage, so quarkus-junit might be a better choice for the artifactId. Or maybe even quarkus-test?

quarkus-junit looks nice.

[gsmet]

We could go with quarkus-junit. My problem with this is: what if they introduce a brand new version that breaks the compatibility entirely and we want to support bother versions at the same time.

Now I'm not sold with the names, we can adjust but it's not really easy to find something that is future proof given we have no idea what the future will be.

[gsmet]

As for quarkus-junit6, why not but the thing is that I really don't want to support both JUnit 5 and 6 given they are very very similar and as @mkouba said more an evolution.
So if we did that, I think I would add some relocations to rewrite junit5 to junit6 anyway and keep only one version.

[geoand]

I really don't want to support both JUnit 5 and 6

I couldn't agree more. We should only support one

[mkouba]

We could go with quarkus-junit. My problem with this is: what if they introduce a brand new version that breaks the compatibility entirely and we want to support bother versions at the same time.

Like a replacement for Jupiter? 🤔 That would mean a new programming model/extension model and I don't think we will be able to support multiple extension models easily...

Now I'm not sold with the names, we can adjust but it's not really easy to find something that is future proof given we have no idea what the future will be.

💯

[gsmet]

Like a replacement for Jupiter? 🤔 That would mean a new programming model/extension model and I don't think we will be able to support multiple extension models easily...

Well at some point we had a JUnit 4 artifact IIRC. If they push a brand new version of JUnit that breaks everything, we will probably need new artifacts and yes a brand new implementation. And we might want to support both models for a while. Now, we could decide to rename the old ones to a disctinctive names and keep quarkus-junit for the latest.

I'm fine with moving to quarkus-junit. Let me know if it all works for you... because given it's a simplification, it will be annoying to rename it afterwards.

[geoand]

I'm fine with moving to quarkus-junit

Fine with me as well

[gastaldi]

No objections, but thinking ahead how about quarkus-test as @mkouba suggested earlier? That would save us the hassle of renaming again if Junit brand is renamed to something else

[holly-cummins]

No objections, but thinking ahead how about quarkus-test as @mkouba suggested earlier? That would save us the hassle of renaming again if Junit brand is renamed to something else

That seems too generic to me; it doesn't give people enough information about what's inside. In particular, it's not obvious from the dependency name that you wouldn't need JUnit on your classpath, because this is giving you JUnit.

It would also rule out some future in which we decide we don't have enough work and want to support both JUnit and a cool new challenger testing framework. It would kind of work if we switched from JUnit to CoolNewChallengerTest, but I'm not sure we'd want the name to stay the same if we did such a massive breaking change.

[aloubyansky]

We also could create something on our own and name it quarkus-test.

[geoand]

Obviously, the only constant in technology is change, but given what we've seen in the past few years, I don't think that many people are asking for / and no one I know of is working on a new unit test framework in Java - JUnit has won, and rightly so, as it is awesome.
Moreover, I don't envision that JUnit itself will introduce some massive programming model change - it uses what most of the enterprise Java community has settled on, i.e., an annotation-based model based on a well-defined lifecycle and by all accounts, users are happy with it.

I don't see the JUnit 4 vs TestNG vs Spock situation repeating itself any time soon (and I'd be willing to put my money where my mouth is on this :)).

Calling the extension quarkus-junit seems like the most pragmatic option to me as it conveys the functionality of the dependency, and if JUnit 7 comes along at some point and has some breaking changes - so be it, we and users deal with analogous situations in other extensions all the time.

[gsmet]

Yeah, I'm -1 for quarkus-test and I'm fine with quarkus-junit.

If nobody objects by Monday evening, I will go do that on Tuesday.