In this chapter, we will cover the following recipes:
- Creating spies in code
- Creating spies with custom configuration
- Creating spies using annotations
- Creating partial mocks
- Creating partial mocks of final classes with
delegatesTo() - Creating spies of final classes with PowerMock
Before going into the details regarding how to create a spy, let's first consider what a spy really is. It's an object that may have predefined answers to its method executions, whereas by default it calls the real implementation. It also records the method calls for further verification. So how does it differ from any other test double? Well, apart from the fact that you can stub its methods, you can also verify its behavior. From the theoretical point of view, a spy is nothing but a partial mock, whose advantages and risks have been described in greater depth in the introduction to the previous chapter.
In general, you should use neither spies nor partial mocks in a well-designed code base. If you do use them, it most likely means that you are violating the S in the SOLID principles (described in more depth in the previous chapter). Let's have another look at that principle as a reminder.
If you are stubbing only some methods from the mock and you'd prefer that the rest of them execute their real implementations, then it is most likely that your object is doing too much. Consider splitting it into pieces. There are some cases where you would like the real computation to take place by default but you might, however, want to verify whether a particular method was executed. (Imagine the business requirements where your company pays a lot of money for each web service call. I will talk about cases in which the verification of implementation does make sense in Chapter 6, Verifying Test Doubles.)
In this chapter, we will take a closer look at spies and partial mock creation.
Note
A standard reminder that you will see throughout the book is as follows:
Because I am very fond of 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 in all of the test cases to make the code even more readable and intuitive. Also, please read Szczepan Faber's blog (author of Mockito) about the given, when, then separation in your test methods, from http://monkeyisland.pl/2009/12/07/given-when-then-forever/, since these separation methods are omnipresent throughout the book.
Some of the methods mentioned might not sound too clear, or the test code may look complicated, but 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. I would like you to take a look at nice tests and get acquainted with Mockito syntax from the very beginning. What is more, I'm using 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.