Info about _Mockito Made Clear_

[Kenneth A. Kousen]

Hi all,

I'm glad to be here this week talking about my new book, Mockito Made Clear. For those who aren't aware of the book, let me give you a few details about it:

- The home page for the book is at https://pragprog.com/titles/mockito/mockito-made-clear/
- The book is part of the "Pragmatic Answers" series, which means: (1) it's ebook only, without any DRM, (2) it's short (about 75 pages or less), and (3) it's inexpensive, at under $10 US.

I teach a lot of software development training courses. That's my day job. Over the years I've found that a lot of students in my Mockito courses (and testing courses in general) are not sure where tools like Mockito fit. Mockito is a Java library that automatically generates mocks, stubs, and spies for you, but many developers don't know what those terms even mean or how they are intended to be used. The Mockito documentation doesn't really help -- the home page is at https://mockito.org, but the actual docs are at https://javadoc.io/doc/org.mockito/mockito-core/latest/org/mockito/Mockito.html, but while they're great for telling you how to use the Mockito API, they don't explain what Mockito is for or how it can help you.

That's why I wrote the book. My intent was to create a short, easy to read primer that shows what Mockito can do, helps you understand some of the more confusing parts that have arisen in the API, and show some basic use cases where it might make your development job easier.

I'll have more to say as the week goes on, but let me end this post with a couple of links:

* The GitHub repository for the book is at https://github.com/kousen/mockitobook. It uses a Gradle build file, with an included Gradle wrapper that I updated to the latest version this morning.
* I've written a series of posts on Medium (because the publisher has a publication there), but if you'd like to see my introductory video on why you might want to use Mockito at all, see https://www.youtube.com/watch?v=IRYYL61-GNk . That's part of my own YouTube channel, Tales from the jar side, at https://www.youtube.com/@talesfromthejarside. I'm planning to add another video in that series this week.
* For the past four years, I've been sending out a free weekly newsletter, also called Tales from the jar side, hosted on Substack: https://kenkousen.substack.com.

I hope some or all of that is helpful for you.

Ken

[Jignesh Patel]

Thank you very much for all these information. Just purchased one.
Wondering if there is maven based configuration provided?

[Kenneth A. Kousen]

I don't have a Maven pom in the repository, but the coordinates for the dependencies are the same. I'll probably add a pom now that you mention it. :⁠-⁠)

Hope you like the book.

[Randy Tong]

thanks sharing

[Kenneth A. Kousen]

I added a pom.xml file to the GitHub repository (https://github.com/kousen/mockitobook), along with a Maven wrapper (mvnw and mvnw.cmd scripts).

[Jignesh Patel]

how to handle private method which is called inside the testing method? In your book there is a section which mention that there is nothing wrong in private fields and methods so that is very encoring.

[Kenneth A. Kousen]

There's a big difference between testing a private method and mocking a private method. To test a private method, you use regular Java reflection along with a tool like JUnit. You don't need Mockito for that.

If you want to mock a private method, the question becomes, why? A mock stands in for a dependency of the class you're actually testing, and that class shouldn't be calling private methods in its dependencies at all. It shouldn't even be aware that the dependencies have private methods, by definition.

So if you want to test a private method, that's fine, though risky, because the whole point of making a method private is that its implementation can change at any time without warning. Your test may work, but it will be fragile and may be forcing the developer into a specific implementation.

Mocking a private method, however, is not currently supported and not likely to be in the future for the reasons discussed above.