Mockito: Where Everything Is Made Up and the Versions Don’t Matter
Upgrading my Mockito Book Repository to V5
One of the funniest shows ever was an improvisational comedy called Whose Line Is It Anyway? The American adaptation of the British show was hosted by Drew Carey and featured Ryan Stiles, Colin Mochrie, plus a rotating cast of guests like Wayne Brady and Greg Proops. Carey would throw out random ideas for a scene (along with audience), and the players would ad lib a scene that somehow fit. The show was a laugh riot.
I mention the show mainly for Drew Carey’s introduction:
🤣 The show where everything is made up and the points don’t matter.
I think of that every time Mockito — the Java testing framework for generating mocks, stubs, and spies — releases a new version.
Semantic Versioning and Mockito 2 to 3 to 4
The idea of semantic versioning, followed by most major software projects, is that version numbers divide into (at least) three parts: x.y.z, where x is the major version, y is a minor version, and z is a patch version. Breaking changes are indicated by a major version update. New, non-breaking features increment the minor version, and all other non-breaking changes cause the patch number to go up.
Prior to the latest update of Mockito, its release version was 4.11.0, so a jump to Mockito 5.0.0, the new current version, implies major changes. The same is implied by the jump from 3.12.4 to 4.0.0, or from 2.28.2 to 3.0.0. That expectation doesn’t quite hold up.
Let me summarize the “big changes” in each jump in major number, based on the releases page for Mockito at GitHub:
- v1.* to v2.* was a big deal, as several major parts of the API were revised. You really did have to undertake a significant porting job to upgrade tests from version 1 to version 2.
- In v2.* to v3.*, the only real change was that users needed to use Java 8. That’s pretty much it, so if you were already using Java 8, you didn’t have to do anything.
- Going from v3.* to v4.*, the team removed many of the features that had been marked as deprecated. Again, if you weren’t using any deprecated classes or methods, you were good and didn’t have to rewrite anything.
Honestly, I’ve never seen a Java library that required so little on the part of the client when going from version 2 to 3 to 4. As long as you were using Java 8 or above and avoided deprecated classes and methods, all you had to do was recompile and all the tests worked as before.
(This summary is a bit of an oversimplification, of course. Each version involved lots of bug fixes and other small modifications, but it’s generally the case.)
What’s New In Mockito 5?
So what changed going from Mockito 4 to Mockito 5? The release page summarizes the changes:
- Switch the default mockmaker to mockito inline.
- Update the minimum supported Java version to 11.
- Add a new
type()method toArgumentMatcherthat works better with varargs.
That’s it. The first point is fairly significant, but again, most Mockito users may already be ready for that change. If you ever used the Mockito abilities to mock a static method or a final class or method, you needed the mockito-inline dependency. Now that dependency is built into the core, so instead of adding the inline dependency, you can just go with the core and be finished. There are slight differences in the details, but from a user perspective, it’s as clean and simple as imaginable.
The mandate to use Java 11 as a minimum is important, since that debate is going on in much of the Java industry right now. Java 8 is seriously out of date (it was released in March 2014), and, following the six-month release schedule adopted with Java 9, there’s been a new major version of Java every March and every September ever since. The current version is 19, though the current long term support (LTS) version is 17. Companies these days normally use one of the three LTS versions: 8, 11, or 17. Most market-share surveys suggest that Java 8 still owns about 40–45 percent of the market, Java 11 is another 45–50 percent, and the rest are tiny — though Java 17 is growing. A move to Java 11 as a minimum is therefore significant, but not unreasonable. Moving to a minimum of Java 17, as the Spring Framework recently did, is a much bolder move.
The last change, adding the type() method to ArgumentMatcher, is completely new, but comes up only when the API you want to test takes a variable number of arguments and you want to distinguish between one argument and many. That change is helpful, but for what is mainly an edge case.
Upgrading to Mockito 5
I have a GitHub repository that includes lots of Mockito tests because it is associated with my new book, Mockito Made Clear. I knew that Mockito 5 was coming, but wasn’t sure exactly what was going to be in the new version. Of course they managed to release version 5 right before my book came out, though I’m trying not to take that personally. When I saw the release on the morning of January 14, 2023, I immediately went to my repository and changed the version to 5.0.0 and did a full rebuild.
As you might expect after this build up, nothing changed. Everything worked exactly the way it had before. I also replaced the mockito-inline dependency with mockito-core (though I could have just left that alone), and again, everything worked exactly the same way.
In effect, like the previous two version upgrades, this is a version upgrade that doesn’t matter. That’s a bit of an exaggeration, of course, but as long as your code was compiled for Java 11, you’re good. If you’re still on Java 8, the only feature of Java I used beyond that was the HTTP client introduced in Java 11, and I included a work-around for that if you’re still on Java 8.
For my book’s code, other than that single example, everything else works for Java 8, 11, and 17, and for Mockito 3, 4, and now 5. Feel free to grab anything in there as part of your learning path to understanding Mockito.
Now I can stop worrying about the upgrade and get back to watching old Whose Line episodes on YouTube.
Buy the book:
Keep up with the author:
