Mockito Mock Example
In this lesson with Mockito, we will learn what is at the core of Mockito, which surprisingly is, mocks!
Mock is an object that has predefined answers to method executions made during the test and has recorded expectations of these executions.
Steps for creating Mockito TestNG example.
Step 1: Create a simple java maven project.
Adding to classpath, using Maven
Step 2: The fastest way to add Mockito to your project is using Maven dependency.
This dependency is simple enough and does not bring any additional or redundant libraries. See here for latest versions of the library.
As we will also be using some JUnit functionality, we will also need it’s dependency. Let’s add it next,
Your pom.xml will look as below:
< project xmlns = "http://maven.apache.org/POM/4.0.0" xmlns : xsi = "http://www.w3.org/2001/XMLSchema-instance"
xsi : schemaLocation = «http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd» >
Creating a Mock
A mock needs to be created before it is actually used, just like anything else. We can use the mock() method in four separate ways to create a mock.
- mock(Class classBeingMocked): This method creates a mock of a given class with a default answer set to returning default values. This is the most used method in tests.
- mock(Class classBeingMocked, String name): This method creates a mock of a given class with a default answer set to returning default values. It also sets a name to the mock. This name is present in all verification messages. That’s very useful in debugging, since it allows you to distinguish the mocks.
- mock(Class classBeingMocked, Answer defaultAnswer): This method creates a mock of a given class. In other words, all of the nonstubbed mock’s method will act as defined in the passed answer.
- mock(Class classBeingMocked, MockSettings mockSettings): This method creates a mock of a given class with customizable mock settings. You should hardly ever need to use that feature.
Using mock()
Step 3: Let’s say you have a Customer class and you want to test calculate bill method of customer class. Bill calculation will depend on list of items customer purchased. We will use Mockito’s mock method to actually mock the items and add to the list.
In this way, we will be able to test calculate bill method without actually adding real items to listOfItems.
Let’s create a Customer class.
Create an interface named Item as below.
Now let’s create a test class which will actually test customer’s calculateBill method.
We have mocked Item i1,i2 and i3 here and used Mockito’s when,thenReturn method to mock behaviour in case getName and getPrice method getCalled.
Step 4: When you run the program, you will get below output:
Another example
Code that instantiates objects using the new keyword directly makes testing difficult. By using the Factory pattern you move the creation of the object outside of the code to be tested. This gives you a place to inject a mock object and/or mock factory.
We start by creating a testable Foo class and FooFactory implementation.
Now you can pass in a mock factory in the test that will create a mock Foo or a Foo of your choosing. Let’s use Mockito to create the mock factory.
Note: Now, the factory that instantiates Foo must be able to access the constructor, so, it should not be made private.
What are answers? When to use them?
In our examples above, we used thenReturn(…) because we simply wanted to return a mocked object i.e., Foo. But what if we want to do some processing based on the parameters passed to the method, create(100, 101) in our case.
thenAnswer() vs thenReturn()
Answer specifies an action that is executed and a return value that is returned when you interact with the mock.
Simplest example to use a parameter which was passed to when(…) is to return it. This can only be done using thenAnswer(…).
In above example, we get the parameters and just use it in creating a Foo instance using factory method after swapping them.
Mocking with Annotation with different default answers
Usually, you won’t ever need to create a custom answer for Mockito, there are plenty of them already bundled in Mockito and there is no need to reinvent the wheel. Why would you want to create a custom answer anyway? Let’s take a look at a couple of possible answers to that point:
- It is probable that for debugging the app, you would like to log the arguments that were passed to the stubbed method.
- You want to perform some business logic on the passed argument rather than just return some fixed value.
- You want to stub asynchronous methods that have callbacks.
If you thought it over and still want to create a custom answer, please check if there isn’t one already existing in Mockito.
In the provided Mockito API, you can find the following answers in the AdditionalAnswers class (check the Javadoc of that class for examples):
- returnsFirstArg: This answer will return the first argument of the invocation
- returnsSecondArg: This answer returns the second argument of the invocation
- returnsLastArg: This answer returns the last argument of the invocation
- returnsArgAt: This answer returns the argument of the invocation provided at the given index
- delegatesTo: This answer delegates all methods to the delegate (you will, in fact, call the delegate’s method if the method hasn’t already been stubbed)
returnsElementsOf: This answer returns the elements of the provided collection.
Продвинутое тестирование с помощью Mockito
Сегодня мы познакомимся с продвинутым тестированием. А точнее с библиотекой Mockito. Даже и не думайте увильнуть от этого дела.
Во-первых, эта библиотека – это стандарт в тестирование Spring’а. Который фактически является стандартом в отрасли Java-backend разработки.
Во-вторых, тебе придется писать тесты для своего Spring-кода . Единственный способ понять, что написанный тобой бекенд работает как нужно – это вызывать методы его API . И сделать это с помощью тестов в 10 раз легче, чем без них. Ты сам в этом убедишься.
Добавить библиотеку Mockito в ваш pom.xml можно с помощью кода:
org.mockito mockito-junit-jupiter 4.2.0 test Весь исходный код проекта Mockito можно найти на GitHub.
1.2 Mock-объекты
Так что же такое эта Mockito и чем она так хороша?
В процессе развития и становления тестирования очень часто возникала необходимость вместо реального объекта подсунуть коду какую-нибудь «заглушку».
Например, тестируется код, который работает с базой данных и что-то там меняет. Хорошо чтобы перед каждым тестом состояние этой базы было одним и тем же (иначе тесты будут разные). И базу хотелось бы попроще, чтобы быстро эти состояния откатывать.
Или, например, ты тестируешь код, который рассылает полезные SMS. А для непосредственно рассылок он использует какой-нибудь платный SMS Gateway. Хорошо бы для тестирования кода подсунуть ему некий виртуальный Gateway, чтобы не рассылать сотни SMS непонятно кому.
Или твой код запрашивает данные у других веб-серверов, которые банально недоступны на тестовом сервере. Или ты пишешь код для интернет-платежей, который нужно 50 раз протестировать, и только потом допускать к реальным финансовым каналам.
Думаю, вы поняли… Виртуальные объекты или как их еще называют объекты-заглушки очень полезная штука.
И тут возникает сложность – в Java-то статическая типизация. Значит, чтобы вместо объекта типа ReadDatabase присвоить переменной ссылку на объект VirtualDatabase , нужно унаследовать класс VirtualDatabase от RealDatabase .
Затем оказывается, что у класса RealDatabase куча приватных методов и переменных, которые хранят ссылки на другие реальные объекты, и нормальную заглушку таким образом не напишешь. В теории хороший, но на практике тупиковый вариант.
И тут нам на помощь приходит DynamicProxy (более подробно можно почитать), которые появились еще в Java 5. Она позволяет создавать виртуальные объекты, к которым у компилятора нет претензий.
Такие виртуальные объекты называют mock’ами (от слова mock – макет). Библиотека Mockito смогла вознести работу с этими моками на небывалую высоту. Отсюда, кстати, и название библиотеки.
1.3 Аннотация @ExtendWith
Библиотека Mockito отлично работает вместе с JUnit, ее можно даже рассматривать как его расширение.
Есть два способа активировать работу библиотеки Mockito в ваших unit-тестах. Первый способ – это добавить специальную аннотацию:
@ExtendWith(MockitoExtension.class) public class MockitoAnnotationTest Второй способ – включить ее работу вызвав метод openMocks() :
public class MockitoAnnotationTest < @BeforeEach public void init() < MockitoAnnotations.openMocks(this); > > Чаще всего ты будешь видеть первый вариант, но иногда полезно знать, что есть и второй.