It seems to works flawlessly with Gradle (see repository here)
That’s awesome! Glad to hear that
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 opened https://github.com/scalameta/munit/issues/41 to track this.
That’s a shame. MUnit uses the conventions I’ve used in my personal projects for several years. It would probably make sense to try and use the same order as
org.junit.Assert. The reason the “obtained” case comes first is because the “expected” is often a large hardcoded expression/string like this
val obtained = someMethod()
"""|val x = 42
|val y = 43
|... more lines
It would not read as nicely with the arguments swapped the other way around. (Note: I’ve primarily worked on tooling projects like scalafmt/scalafmt/metals that assert a lot of behavior against multiline strings containing Scala source code, I understand this does not reflect most Scala projects in the real world)
JUnit reports seem to be generated with incorrect class name suite; it uses the name of an arbitrary (first?) test case in the suite.
That could very well be, I haven’t used the JUnit reports myself so much. Looking at the JUnit XML reports that are generated by sbt it looks like the test suite name is correct, however
<testsuite hostname="tw-mbp-lgeirsson" name="munit.AssertionsSuite" tests="3" errors="0" failures="0" skipped="0" time="0.079" timestamp="2020-02-03T11:49:10">
Those reports are generated by the sbt test interface so there could be differences. Please open an issue with a reproduction and we can look into it.
Do you think my “chained test cases” use-case can be achieved with MUnit without
At a quick glance I believe so. You can override
def munitTests() to return exactly what tests should run in what order. See example here https://scalameta.org/munit/docs/filtering.html#filter-tests-cases-based-on-a-dynamic-conditions