You can configure MUnit to use sbt loggers, which will probably make the test reports appear in-order when running parallel tests
In the Metals build, we enable the sbt loggers in CI only https://github.com/scalameta/metals/blob/3c8bdfad6b7a873c683cc57e6caae0767e98ef4f/build.sbt#L532-L539
By the way, reports work properly out of the box, without any additional configuration, with
bloop for some reason.
How are you? Looks like we are finally getting close to a Scala Native
scalafmt.
Not sure if anyone else would be interested in this, but I created a prototype wrapper DSL to allow me to write my unit tests like I do in ScalaTest, but use MUnit: https://gist.github.com/darkfrog26/da9eebb9f70e9b3ac09e5e066ddc4f44
it's just a prototype, but I wasn't sure if anyone else would care
And looking at another prototype/issue it looks like they didn't want to raise the complexity.
The “no DSL” part is quite intrinsic in the design of MUnit. The general idea is that it complicates the way in which to write tests, causing divergence in style and often shifting the focus to picking the right “word”.
(That’s my opinion, but I think @olafurpg’s one isn’t too far)
That said, as you demonstrated, it’s not too hard to define a custom DSL on top of MUnit core functionalities. It’s very unlikely that it will be included to MUnit though
i think it makes sense to write a DSL to simplify the migration from ScalaTest
My experience with ScalaTest DSLs is that people use different styles, which has caused problems when contributors send a PR using a different ScalaTest style than what’s used in the repo.
The reason we don’t support official ScalaTest shims is because it’s a lot of effort to support 100% fidelity
if people write their own DSLs it sets the expectation that not all ScalaTest features are supported
My only complaint about MUnit so far though is that there doesn't seem to be any way to create more structured test blocks to more readily comprehend the output. For example, I might have a test that defines three types of tests and I want them to define those groups and then indent tests underneath it.
Related discussion. I’m OK with adding something like describe
it comes up frequently
i personally haven’t felt the need so haven’t prioritized it. I opened a PR once that added arbitrary nesting but we agreed that was unnecessarily complex
I asked a question on how fixtured can return test info on the scalatest mailing list here, but I think the same question applies to munit.
(I am using both, as akka still has its tests in scalatest, and it is actually interesting to see how the two differ)
I have a scalatest example here https://github.com/co-operating-systems/Reactive-SoLiD/blob/master/src/test/scala/run/cosy/ldp/TestSolidRouteSpec.scala#L78
The
The
withServer method could do with extra sections such as "creating blog post" in ... etc
I also have a munit one with a Fixture here that could do with having subsections in the fixture https://github.com/co-operating-systems/Reactive-SoLiD/blob/master/src/test/scala/run/cosy/ldp/fs/TestAttributesFn.scala
I can see myself adding more and more tests in both those fixtures, but the output on the console will only contain info about the outer fixture useage.
Have you tried using
Fixture[T] instead of FunFixture[T]?
that's the low level API that gives you hooks for beforeAll/beforeEach/afterAll/afterEach
You can then use
test("name") { ... } like normal and access the fixture with tmpDir()
I personally prefer
Fixture[T] over FunFixture[T] because it's more flexible, requires less boilerplate, easier to compose mutiple fixtures
ah great. That's probably what I was looking for... I'll check it out. Thanks :-)
I found that in scalatest I can just write info("some message"), which appears in the console, and also helps me find out better where something broke.
Or more generally is anyone using munit with any Docker/container test library? There is https://github.com/testcontainers/testcontainers-scala also.