Use the for3Use2.13 trick… but this can have a lot of issues, especially if there are macros involved (which is likely).
Use Mockito directly witjout any Scala wrapper.
Contribute the support of Scala 3 for mockito-scala.
Search for another Scala wrapper of Mockito, or write your own.
Don’t use Mockito at all.
Don’t use Scala 3.
Personally, I would suggest following a different testing style altogether, especially for a new project.
But, I won’t elaborate further since you didn’t ask about testing recommendations per se.
In general, I don’t write too many traditional unit tests anymore.
Rather, I would usually focus on writing scenario tests: A Philosophy of Testing 1: Introduction | by Mark "Justin" Waks | Medium using weaver.
Then I would only write unit tests for complex things, such as involved algorithms or custom data structures.
Finally, I would also usually mix that with some form of property-based testing using ScalaCheck, if it makes sense. But, using fixed inputs for known bugs / regressions.
Thanks! Although I’ll footnote that the scenario-test approach tends to be optimal for testing backend services, not necessarily as much for some other sorts of problems. (Eg, when testing libraries, I’d focus much more heavily on property-based testing.)
But agreed that, if one is looking at Mockito, a scenario-testing approach is usually better in the long run: it requires more upfront investment, but pays off big as the system matures and the number of tests grows.
Mockito (and traditional unit testing in general) makes some sense in “classic OO” code, where each class is basically a complex mutable state machine that needs heavy testing in isolation. That’s traditional Java style, and you can do that in Scala (some folks do). But typical Scala idiom has gone in very different directions over the years, and most unit tests are a waste of time for the sort of strongly-typed, immutable, relatively “lightweight” classes that are more common in typical Scala code.
I’ll note that I’ve specifically been bitten quite badly by Mockito in the past. IIRC, it isn’t strongly-typed enough to really fit well with idiomatic Scala code, and is too null-friendly. I had one project back in 2017 where I lost months fixing all the Mockito tests while I was doing a big library upgrade for my then-new employer – the Mockito tests just wound up annoyingly brittle and hard to track down and fix, in a very counter-productive way.
Indeed, the scenario-testing approach really got nailed down as a reaction to that bad Mockito experience: I wanted something better for the new services I started building after that. So I took the ideas I’d been evolving for testing Querki and fleshed them out more thoroughly, eventually resulting in the above-linked articles.
