Mockito Made Clear
Using the Gradle Build File
I have a new book available, called Mockito Made Clear, which is currently in beta from Pragmatic Programmers:
The book is about understanding the basics of the Mockito testing framework, including what it does, where you might want to use it, and how it can help make your job easier.
You can access all the code in this GitHub repository. The repo comes with a Gradle build file (I plan to add a Maven pom as well, but haven’t completed that yet). This post shows you what that build file includes and why each dependency is there.
Here is a gist with the complete contents of build.gradle:
Beginning at the top, this is a Java project, so I’m using the java plugin from Gradle. Next, the statementapply from:versions.gradle means to include the contents of the file versions.gradle, which contains variables for all the version numbers of the dependencies. Whenever versions update, I plan to update that file, and the build will then use the resulting settings.
The group and version properties aren’t really important, but are set anyway. They would matter if I was producing a library, but here you can safely ignore them.
The next part refers to the Java toolchain support from Gradle. This project uses at least one feature from Java 11: the HttpClient class, to call RESTful web services in two of the demos, one called Astro and one for Wikipedia.
📝 Note that the HttpClient API is the only Java feature used that requires a version beyond Java 8.
In the Astro demo, I’ve included two implementations in the source code: one that uses the HttpClient and another uses the Retrofit library (which works under Java 8). The Wikipedia demo downloads data from, naturally enough, Wikipedia. Everything else in the repository compiles and runs correctly under Java 8. Since much of the Java community is currently on Java 11 (or above) or moving there, this seemed like a reasonable compromise.
The Java toolchain mechanism in Gradle will detect any existing version of Java 11 on the client machine and use it automatically. If you are on Java 11 or beyond and you don’t want to use that feature, feel free to delete that section from the build file locally. I personally find the toolchain mechanism convenient, because I normally run on Java 17, and this allows me to make sure I’m using only Java 11 features in my repository whenever I do a Gradle build, without having to modify my local settings.
The repositories block simply includes mavenCentral, implying all the dependencies are downloaded from the public Maven central repository.
Next come the individual libraries in the dependencies block. The book uses JUnit 5 for all of its tests, so the junit-jupiter coordinates are included. The so-called vintage engine is also added, because Mockito works with JUnit 4 as well, and this way you can compile and run JUnit 4 tests if you wish. None of the existing tests use JUnit 4, but I may add a couple for demonstration purposes.
After that are the Mockito dependencies. The first dependency, for mockito-core, is commented out. Normally, you’d need that, but instead I’ve used the mockito-inline dependency, which brings in the core as a transitive dependency automatically. The inline dependency also allows you to mock final classes and final methods, and the book code includes a few examples of that. The other Mockito-based dependency is for mockito-junit-jupiter, which is the JUnit 5 extension for Mockito. That extension allows you to annotate tests with @ExtendWith(MockitoExtension.class), along with annotations like @Mock and @InjectMocks, so they will work as shown in the book.
The dependency for the AssertJ testing library comes after that. AssertJ is a “syntactic sugar” library that doesn’t change JUnit assertions, but does make them a bit more readable, especially for native English speakers. Its use here is optional, but convenient.
The last three libraries included in the dependencies block are for Retrofit, which accesses RESTful web services and converts their responses to Java classes, and two JSON parsing libraries, Jackson and Gson. Both of those are used just for working with the Astro and Wikipedia examples.
The last section of the build file is the test block, which tells Gradle (1) we are using JUnit 5 for our tests, and (2) to run the tests in parallel using four separate threads. Feel free to change the argument to the maxParallelForks method to whatever value you like.
Hopefully that gives you all the information you need to understand everything in the build file. Please leave a comment if anything is unclear or you have any questions. :)
Pick up a copy of Mockito Made Clear, now in beta from The Pragmatic Bookshelf:
Save 35 percent on the ebook with coupon code mockito_medium_35. Coupon codes are not valid on prior purchases.
Keep up with the author:
