Support JUnit 5

[olafurpg]

From https://contributors.scala-lang.org/t/announcing-munit-a-new-scala-testing-library/4007/11?u=olafurpg

It does not currently support JUnit 5, at least not with gradle – trying to run with org.junit.jupiter:junit-jupiter-engine doesn’t work, and instead the “vintage” engine has to be used.

I'm not so familiar with what is needed to make this work but I think it's worth looking into.

[eyalroth]

It's worth noting that ScalaTest has a similar issue with what seem to be relevant information.

[olafurpg]

That’s good to know. Is there a way to support both JUnit 5 and 4 at the same time?

[eyalroth]

I'm not sure. My guess would be that either the vintage engine (junit 4) knows how to work with (junit 5) extensions, or that each engine will exclusively use the appropriate method -- vintage will use runners, jupiter will use extensions -- so they can coexist.

I don't have any experience with extending junit myself, but this and this look like good guides on the topic.

[olafurpg]

I've started working on an upgrade to JUnit 5 and hope to get a PR out soon.

I opened an issue for IntelliJ to confirm what changes are needed to keep the IntelliJ integration working https://youtrack.jetbrains.com/issue/SCL-19607

I have confirmed that the Gradle integration continues to work with useJUnitPlatform. The junit-vintage test engine will no longer be needed to run MUnit tests. Instead, the scalameta-munit test engine should be used and it's automatically registered as long as you depend on the MUnit artifact (you shouldn't need to explicitly declare the scalameta-munit test engine, unless you somehow disable automatic registration). I tried to see if it was possible to build on top of the junit-jupiter test engine but the API was too limiting.

I suspect this upgrade will also fix the incorrect HTML report issues in Gradle, although I haven't confirmed yet.

Overall, I'm really excited about this upgrade since JUnit 5 has a lot of nice improvements!

[armanbilge]

Copy-pasting some Discord notes from Olafur:

The biggest change is how you notify updates, it's dramatically simpler with JUnit 5 while JUnit 4 requires pretty weird ordering on task notifications I'd probably just upgrade to JUnit 5 and drop the old logic to report notifications for JUnit 4 If I were to look into JUnit 5 again I'd try to approach it like this

• work with a clean branch off main
• remove all the Java code from junit-interface, reuse same Scala code for JVM/JS/Native
• refactor MUnitRunner to accept JUnit 5 APIs instead of JUnit 4 RunListener, this is where you might want to copy-paste stuff from my old branch

https://discord.com/channels/632642981228314653/671278431102697472/990954218657546240

[armanbilge]

Part of the mystery is where @olafurpg's branch is, so we can use it as a copy-pasta source as suggested :)

[gabro]

I suppose it would be this one? https://github.com/olafurpg/munit/commit/50cd80a6f274f48ccc309b47b7d213efa274eddc

[armanbilge]

Aha, thanks!

[szymon-rd]

Is it a change requiring a release of a new major (per semver rules)?

[SimY4]

IMO not necessarily if you provide JUnit4 and JUnit5 runner integrations in separate artefacts. ScalaTest has both JUnit4 and JUnit5 bindings (provided via external dependency: https://github.com/helmethair-co/scalatest-junit-runner)