Introduction

For those who don't know Mockito at all, I'd like to write a really short introduction about it.

Mockito is an open source framework for Java that allows you to easily create test doubles (mocks). What makes Mockito so special is that it eliminates the common expect-run-verify pattern (which was present, for example, in EasyMock—please refer to http://monkeyisland.pl/2008/02/24/can-i-test-what-i-want-please for more details) that in effect leads to a lower coupling of the test code to the production code as such. In other words, one does not have to define the expectations of how the mock should behave in order to verify its behavior. That way, the code is clearer and more readable for the user.

On one hand, Mockito has a very active group of contributors and is actively maintained; on the other hand, unfortunately, by the time this book is written, the last Mockito release (Version 1.9.5) have been in October 2012.

You may ask yourself the question, "Why should I even bother to use Mockito in the first place?" Out of many choices, Mockito offers the following key features:

• There is no expectation phase for Mockito—you can either stub or verify the mock's behavior
• You are able to mock both interfaces and classes
• You can produce little boilerplate code while working with Mockito by means of annotations
• You can easily verify or stub with intuitive argument matchers

Before diving into Mockito as such, one has to understand the concept behind System Under Test (SUT) and test doubles. We will base our work on what Gerard Meszaros has defined in the xUnit Patterns (http://xunitpatterns.com/Mocks,%20Fakes,%20Stubs%20and%20Dummies.html).

SUT (http://xunitpatterns.com/SUT.html) describes the system that we are testing. It doesn't have to necessarily signify a class or any part of the application that we are testing or even the whole application as such.

As for test doubles (http://www.martinfowler.com/bliki/TestDouble.html), it's an object that is used only for testing purposes, instead of a real object. Let's take a look at different types of test doubles:

• Dummy: This is an object that is used only for the code to compile—it doesn't have any business logic (for example, an object passed as a parameter to a method)
• Fake: This is an object that has an implementation but it's not production ready (for example, using an in-memory database instead of communicating with a standalone one)
• Stub: This is an object that has predefined answers to method executions made during the test
• Mock: This is an object that has predefined answers to method executions made during the test and has recorded expectations of these executions
• Spy: These are objects that are similar to stubs, but they additionally record how they were executed (for example, a service that holds a record of the number of sent messages)

An additional remark is also related to testing the output of our application. Throughout the book, you will see that the tests (in general, all of them apart from the chapter related to verification) are based on the assertion of behavior instead of the checking of implementation. The more decoupled your test code is from your production code, the better, since you will have to spend less time (or even none) on modifying your tests after you change the implementation of the code.

Coming back to the chapter's content—this chapter is all about getting started with Mockito. We will begin with how to add Mockito to your classpath. Then, we'll see a simple setup of tests for both JUnit and TestNG test frameworks. Next, we will check why it is crucial to assert the behavior of the system under test instead of verifying its implementation details. Finally, we will check out some of Mockito's experimental features, adding hints and warnings to the exception messages. The very idea of the following recipes is to prepare your test classes to work with Mockito and to show you how to do this with as little boilerplate code as possible.

Due to my fondness for the behavior driven development (http://dannorth.net/introducing-bdd/ first introduced by Dan North), I'm using Mockito's BDDMockito and AssertJ's BDDAssertions static methods to make the code even more readable and intuitive in all the test cases. Also, please read Szczepan Faber's blog (author of Mockito) about the given, when, then separation in your test methods—http://monkeyisland.pl/2009/12/07/given-when-then-forever/—since these are omnipresent throughout the book.

Even though some of the previous methods might sound not too clear to you or the test code looks complicated—don't worry, it will all be explained throughout the book. I don't want the book to become a duplication of the Mockito documentation, which is of high quality—I would like you to take a look at good tests and get acquainted with Mockito syntax from the beginning. What's more, I've used static imports in the code to make it even more readable, so if you get confused with any of the pieces of code, it would be best to consult the repository and the code as such.