Mockito проверить

Mocking the interface in a test

package com.logicbig.example;

import org.junit.Assert;
import org.junit.Test;
import org.mockito.Mockito;

public class MyServiceTest {

  @Test
  public void testDoSomething(){
      MyService mock = Mockito.mock(MyService.class);
      int i = mock.doSomething();
      Assert.assertEquals(i, 0);
  }
}

D:\mockito-getting-started-creating-mocks>mvn test -Dtest="MyServiceTest" Scanning for projects...  ----< com.logicbig.example:mockito-getting-started-creating-mocks >----- Building mockito-getting-started-creating-mocks 1.0-SNAPSHOT -----------------------------------------------------------------  --- maven-resources-plugin:2.6:resources (default-resources) @ mockito-getting-started-creating-mocks --- Using platform encoding (Cp1252 actually) to copy filtered resources, i.e. build is platform dependent!  --- maven-compiler-plugin:3.8.1:compile (default-compile) @ mockito-getting-started-creating-mocks --- Nothing to compile - all classes are up to date  --- maven-resources-plugin:2.6:testResources (default-testResources) @ mockito-getting-started-creating-mocks --- Using platform encoding (Cp1252 actually) to copy filtered resources, i.e. build is platform dependent!  --- maven-compiler-plugin:3.8.1:testCompile (default-testCompile) @ mockito-getting-started-creating-mocks --- Nothing to compile - all classes are up to date  --- maven-surefire-plugin:2.12.4:test (default-test) @ mockito-getting-started-creating-mocks ---------------------------------------------------------- T E S T S-------------------------------------------------------Running com.logicbig.example.MyServiceTestTests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.913 secResults :Tests run: 1, Failures: 0, Errors: 0, Skipped: 0 ------------------------------------------------------------------------ BUILD SUCCESS ------------------------------------------------------------------------ Total time:  4.188 s Finished at: 2020-04-17T00:11:00-05:00 ------------------------------------------------------------------------

By default a mock’s method returns either null, a primitive/primitive wrapper value, or an empty collection.
For example 0 for an int/Integer and false for a boolean/Boolean.

How about some stubbing?

// Stub a mock method before interacting.
when(cat.sound()).thenReturn("Purr");
expect(cat.sound(), "Purr");

// You can call it again.
expect(cat.sound(), "Purr");

// Let's change the stub.
when(cat.sound()).thenReturn("Meow");
expect(cat.sound(), "Meow");

// You can stub getters.
when(cat.lives).thenReturn(9);
expect(cat.lives, 9);

// You can stub a method to throw.
when(cat.lives).thenThrow(RangeError('Boo'));
expect(() => cat.lives, throwsRangeError);

// We can calculate a response at call time.
var responses = ;
when(cat.sound()).thenAnswer((_) => responses.removeAt());
expect(cat.sound(), "Purr");
expect(cat.sound(), "Meow");

A quick word on async stubbing

This is because it can lead to unexpected behaviors. For
example:

• If the method is stubbed in a different zone than the zone that consumes the
  , unexpected behavior could occur.
• If the method is stubbed to return a failed or and it
  doesn’t get consumed in the same run loop, it might get consumed by the
  global exception handler instead of an exception handler the consumer applies.

Instead, use to stub methods that return a or .

// BAD
when(mock.methodThatReturnsAFuture())
    .thenReturn(Future.value('Stub'));
when(mock.methodThatReturnsAStream())
    .thenReturn(Stream.fromIterable());

// GOOD
when(mock.methodThatReturnsAFuture())
    .thenAnswer((_) async => 'Stub');
when(mock.methodThatReturnsAStream())
    .thenAnswer((_) => Stream.fromIterable());

If, for some reason, you desire the behavior of , you can return a
pre-defined instance.

// Use the above method unless you're sure you want to create the Future ahead
// of time.
final future = Future.value('Stub');
when(mock.methodThatReturnsAFuture()).thenAnswer((_) => future);

Избегайте заделывания

Хотя мы можем использовать ArgumentCaptor с stubbing , мы обычно должны избегать этого. Чтобы уточнить, в Mockito это обычно означает, что следует избегать использования ArgumentCaptor с Mockito.когда . При стаббинге вместо этого мы должны использовать ArgumentMatcher .

Давайте рассмотрим несколько причин, по которым мы должны избегать ударов.

3.1. Снижение Читаемости Теста

Во-первых, рассмотрим простой тест

Credentials credentials = new Credentials("baeldung", "correct_password", "correct_key");
Mockito.when(platform.authenticate(Mockito.eq(credentials)))
  .thenReturn(AuthenticationStatus.AUTHENTICATED);

assertTrue(emailService.authenticatedSuccessfully(credentials));

Здесь мы используем Mockito.eq(учетные данные) , чтобы указать, когда макет должен возвращать объект.

Затем рассмотрим тот же тест с использованием ArgumentCaptor вместо этого:

Credentials credentials = new Credentials("baeldung", "correct_password", "correct_key");
Mockito.when(platform.authenticate(credentialsCaptor.capture()))
  .thenReturn(AuthenticationStatus.AUTHENTICATED);

assertTrue(emailService.authenticatedSuccessfully(credentials));
assertEquals(credentials, credentialsCaptor.getValue());

В отличие от первого теста, обратите внимание, как мы должны выполнить дополнительное утверждение в последней строке, чтобы сделать то же самое, что и Mockito.eq(учетные данные). Наконец, обратите внимание, что не сразу понятно, к чему относится credentials Captor.capture ()

Это связано с тем, что мы должны создать захватчик за пределами строки, в которой мы его используем, что снижает читаемость

Наконец, обратите внимание, что не сразу понятно, к чему относится credentials Captor.capture (). Это связано с тем, что мы должны создать захватчик за пределами строки, в которой мы его используем, что снижает читаемость

3.2. Уменьшенная Локализация Дефектов

org.mockito.exceptions.base.MockitoException: 
No argument value was captured!

Это происходит потому, что наш метод stubbed не захватил аргумент. Однако реальная проблема заключается не в самом тесте, а в самом методе, который мы тестируем.

Другими словами, он неверно направляет нас на исключение в тесте, в то время как фактический дефект находится в методе, который мы тестируем.

mock и spy

Центральный класс Mockito, через который предполагается обращаться к большей части функционала, — это, собственно, класс под названием (есть также класс , предоставляющий примерно те же возможности в форме, более подходящей для BDD, но здесь я не стану на нём останавливаться). Доступ к функционалу реализован через его статические методы.

Чтобы создать mock класса , я должен сделать всего лишь следующее:

Готово — я получил экземпляр нужного мне класса. Он будет принят любым методом или конструктором, которому требуется параметр такого типа (например, конструктором того класса, который я хочу протестировать). Даже если далее его ожидает проверка с пристрастием, он её пройдёт: не только вернёт , но и — именно . Каким-то формальным образом программно отличить mock-объект от обычного оказывается довольно непростой задачей, что и логично: ведь первый предназначен как раз для того, чтобы быть неотличимым от второго. Однако в составе Mockito для этого есть инструмент — метод . Передав ему произвольный объект, я получу объект класса . Он содержит информацию о том, что этот объект представляет собой с точки зрения Mockito: является ли он mock, spy (см. ниже), как использовался, как был создан и прочее.

Особо нужно упомянуть ситуацию, когда я пытаюсь создать mock для final класса или mock-экземпляр enum либо переопределить поведение final метода. В таком случае при поведении Mockito по умолчанию код выше откажется работать, сославшись именно на это обстоятельство. Однако это можно изменить — достаточно создать в проекте (при стандартном устройстве проектного дерева каталогов) файл и вписать в него строчку:

После этого можно имитировать обычным способом final классы и enum’ы, а также переопределять final методы.

Полученный мной mock в действии максимально безлик: ни один метод при вызове не окажет никакого воздействия на что бы то ни было, а возвращённое значение окажется для объектных типов и для примитивных

Обратите внимание: если метод возвращает коллекцию, mock’ом по умолчанию будут возвращены не ‘ы, а пустые экземпляры коллекций. Например, для это окажется пустой независимо от того, что должен был возвращать реальный метод

А вот в качестве значений массивов, примитивных или объектных, я получу . Поведение по умолчанию (и не только его) можно изменить при помощи функционала класса , но это нечасто бывает нужно.

Так или иначе, в большинстве случаев мне понадобится не поведение по умолчанию, и в следующем разделе я подробно разберу, как задавать вместо него то, которое требуется.

Однако что, если я хочу использовать в качестве заглушки объект реального класса с имеющимся функционалом, переопределив работу только части его методов? Если речь о юнит-тестировании, такая потребность обычно (но не всегда) свидетельствует о том, что в проекте не всё в порядке с дизайном, и в принципе так действовать не рекомендуется. Однако случаются ситуации, когда этого по какой-то причине не избежать. На этот случай в Mockito есть так называемые spy, «шпионы». В отличие от mock’ов, их можно создавать на основе как класса, так и готового объекта:

При создании spy на основе класса, если его тип — интерфейс, будет создан обычный mock-объект, а если тип — класс, то Mockito попытается создать экземпляр при помощи конструктора по умолчанию (без параметров). И только если такого конструктора нет, произойдёт ошибка и тест не сработает.

Поведение spy-объектов по умолчанию идентично поведению обычного экземпляра класса, однако они дают мне те же возможности, что и mock-объекты: позволяют переопределять их поведение и наблюдать за их использованием (см. следующие разделы). Важный момент: spy — не обёртка вокруг того экземпляра, на основе которого он создан! Поэтому вызов метода spy на состояние изначального экземпляра не повлияет.

HOW TO SPY WITH MOCKITO

Why spy?

• Sometimes we do need to call real methods of a dependency but still want to verify or track interactions with that dependency, this is where we would use a spy.
• When a field is annotated with , Mockito will create a wrapper around an actual instance of that object and therefore we can call real implementation and also verify interactions at the same time.
• Some of the behavior of a spy could be mocked if neened.
• in the example below, the dependency behavior is not mocked but still it’s interactions are verified.

Click Here to get the example source code given in this tutorial.

That’s it on this post, please check out the below websites for more cool features, best practices and guidelines on Mockito.

Automatic Mock Injection

We can also tell Mockito to inject mocks automatically to a field annotated with .

When is called, Mockito will:

• Create mocks for fields annotated with the annotation
• Create an instance of the field annotated with and try to inject the mocks into it

Using is the same as we did when instantiating an instance manually, but now automatic.

Mockito will first try to inject mocks by constructor injection, followed by setter injection, or field injection.

Pros:

Easy to inject mocks

Cons:

Doesn’t enforce usage of constructor injection

It is not recommended to use field or setter injection. Using constructor injection, we can be 100% sure no one instantiates the class without injecting its dependencies.

Course Overview

Step List

JUnit

• Step 01 : Need for Unit Testing
• Step 02 : Setting up your First JUnit
• Step 03 : First Successful JUnit. Green Bar and assertEquals
• Step 04 : Refactoring Your First JUnit Test
• Step 05 : Second JUnit Example assertTrue and assertFalse
• Step 06 : @Before @After
• Step 07 : @BeforeClass @AfterClass
• Step 08 : Comparing Arrays in JUnit Tests
• Step 09 : Testing Exceptions in JUnit Tests
• Step 10 : Testing Performance in JUnit Tests
• Step 11 : Parameterized Tests
• Step 12 : Organize JUnits into Suites

Mockito

• Step 01 : Set up an Eclipse Project with JUnit and Mockito frameworks. First Green Bar.
• Step 02 : Example to start understanding why we need mocks.
• Step 03 : What is a stub? Create an unit test using Stub? Disadvantages of Stubs.
• Step 04 : Your first Mockito code! Hurrah!!! Lets use Mockito to mock TodoService.
• Step 05 : Stubbing variations with Mockito. A few mockito examples mocking List class : Multiple return values, Argument Matchers and throwing exceptions.
• Some Theory : Mockito vs EasyMock https://github.com/mockito/mockito/wiki/Mockito-vs-EasyMock
• Step 06 : Introduction to BDD. Given When Then. BDD Mockito Syntax.
• Step 07 : How to verify calls on a mock? Verify how many times a method is called. We will add deleteTodo method to the TodoService.
• Step 08 : How to capture an argument which is passed to a mock?
• Step 09 : Hamcrest Matchers.
• Step 10 : Let’s simplify things with Mockito Annotations. @Mock, @InjectMocks, @RunWith(MockitoJUnitRunner.class), @Captor
• Step 11 : JUnit Rules. Using MockitoJUnit.rule() instead of @RunWith(MockitoJUnitRunner.class).
• Step 12 : Real world Example with Spring
• Step 13 : What is a spy? How to spy with Mockito?
• Step 14 : Some Theory : Why does Mockito not allow stubbing final and private methods?
• Step 15 : Using PowerMock and Mockito to mock a Static Method.
• Step 16 : Using PowerMock and Mockito to invoke a private Method.
• Step 17 : Using PowerMock and Mockito to mock a constructor.
• Step 18 : Good Unit Tests.

Expectations

• You should know Java.
• You are NOT expected to have any experience with Eclipse or Maven.
• We will help you install Eclipse and get up and running with Maven.

Running Examples

• Download the zip or clone the Git repository.
• Unzip the zip file (if you downloaded one)
• Open Command Prompt and Change directory (cd) to folder containing pom.xml
• Open Eclipse
  • File -> Import -> Existing Maven Project -> Navigate to the folder where you unzipped the zip
  • Select the right project
• Choose the Spring Boot Application file (search for @SpringBootApplication)
• Right Click on the file and Run as Java Application
• You are all Set

Refer our TroubleShooting Guide — https://github.com/in28minutes/in28minutes-initiatives/tree/master/The-in28Minutes-TroubleshootingGuide-And-FAQ

Mockito: что это такое и зачем нужно

Говоря коротко, Mockito — фреймворк для работы с заглушками.

Как известно, при тестировании кода (прежде всего юнит-тестировании, но не только) тестируемому элементу часто требуется предоставить экземпляры классов, которыми он должен пользоваться при работе. При этом часто они не должны быть полнофункциональными — наоборот, от них требуется вести себя жёстко заданным образом, так, чтобы их поведение было простым и полностью предсказуемым. Они и называются заглушками (stub). Чтобы их получить, можно создавать альтернативные тестовые реализации интерфейсов, наследовать нужные классы с переопределением функционала и так далее, но всё это достаточно неудобно, избыточно и чревато ошибками. Более удобное во всех смыслах решение — специализированные фреймворки для создания заглушек. Одним из таковых (и, пожалуй, самым известным для Java) и является Mockito.

Mockito позволяет создать одной строчкой кода так называемый mock (что-то вроде основы для нужной заглушки) любого класса. Для такого mock сразу после создания характерно некое поведение по умолчанию (все методы возвращают заранее известные значения — обычно это либо ). Можно переопределить это поведение желаемым образом, проконтролировать с нужной степенью детальности обращения к ним так далее. В результате mock и становится заглушкой с требуемыми свойствами. Ниже я подробно разберу, как это сделать.

Отмечу, что mock можно создать и для тех классов, новый экземпляр которых вообще-то так просто не создашь, в частности, классов с исключительно приватными конструкторами типа синглтонов и утилитных классов, а при минимальной настройке фреймворка — и перечислений (enums).

Выпуск бомбардировщиков

В сентябре 1941 года в виде бомбардировщика был собран восьмой «Москито», заложенный первоначально как разведчик типа PR Mk1. Этот самолет прибыл в ААЕЕ в Боскомб-Даун 27 сентября. За ним 18 октября туда же последовал первый из девяти серийных бомбардировщиков В MkIV Srs.1 (известных также как «переходный разведчик-бомбардировщик», поскольку первоначально заказывали разведчики, а завершили их как бомбардировщики). Обозначение Srs.1 (серия 1) показывало, что самолеты имеют первоначальные короткие обтекатели мотогондол. Все более поздние самолеты имели удлиненные гондолы, введенные для противодействия бафтингу.

MkIV Srs.1 вид сбоку

Оставшиеся В MkIV считались серией 2 (Srs.2) и кроме удлиненных мотогондол имели два подкрыльных подвесных гладко прилегающих бака по 227 литра. Первоначальные бомбардировочные варианты «Москито» были оснащены моторами «Мерлин 21» и «Мерлин 23», и могли нести на внутренней подвеске бомбовую нагрузку в 908 кг: две бомбы по 454 кг или четыре по 227 кг. Перед концом 1941 года прототип бомбардировщика был использован для испытания подкрыльных пилонов, которые сперва были рассчитаны на одну бомбу в 227 кг под каждым крылом. Такой вариант в серии должен был называться В MkV, но серийного производства не было, хотя модифицированный прототип иногда упоминался под этой маркой.

MkIV Srs.1 вид спереди

Всего было выпущено 300 «Москито» В.IV Srs 2. Поставка их началась в апреле 1942 года. Девять из них были собраны в других модификациях, а 27 были позднее переделаны в разведчики. В качестве первой части, подлежащей перевооружению на бомбардировщики «Москито», была выбрана 105-я эскадрилья. Но необходимость удовлетворять потребности истребительных и фоторазведывательных частей привела к тому, что поставка машин поначалу осуществлялась очень медленно. С 15 ноября 1941 года по середину мая 1942 года прибыли только девять В Mk1V Srs.1, использовавшиеся для переучивания экипажей и ознакомительных полетов.

MkIV Srs.1 вид сверху

Первые самолеты серии 2 поступили в эскадрилью в середине мая, когда она располагалась в Хоршэм-Сент-Фэнс (сейчас аэропорт Норвича). Однако четыре Srs.1 были использованы при первых боевых вылетах. 31 мая самолеты поодиночке с интервалами нанесли удар по Кельну; это было непосредственно перед первым рейдом «1000 бомбардировщиков» на этот город. Первые операции не принесли заметных успехов — частично из-за «младенческих болезней» первых серийных самолетов, но в большей степени из-за необходимости отработать лучшую тактику их применения.

«Москито» В.IV Srs.2 вид сбоку

Новые варианты самолетов

Совершенствование бомбардировщиков шло главным образом по линии повышения бомбовой нагрузки и усовершенствования силовой установки. Первый из 10 первых серийных бомбардировщиков был использован как опытная машина с установкой крыльевых бомбодержателей вместо стандартных подвесных баков по 227 литров, стоявших на В Mk1V Srs2.

«Москито» В Mk.IX вид сбоку

Модель	Mosquito B Mk.IV
Экипаж, человек	2
Размах крыла, м	16,51
Длина, м	12,43
Высота, м	4,65
Площадь крыла, м2	42,18
Масса, кг пустого самолета	6080
Масса, кг нормальная взлетная	9900
Масса, кг максимальная взлетная	10152
Тип двигателя	2 ПД Rolls-Royce Merlin 21
Мощность, л.с.	2 х 1480
Максимальная скорость , км/ч	619
Крейсерская скорость , км/ч	491
Скороподъемность, м/мин	816
Практический потолок, м	10400
Вооружение	Бомбовая нагрузка до 908 кг одна 454 кг бомба и две 227-кг бомбы или четыре 227-кг бомбы

В.МкХХ вид сбоку

Что подтверждает ваш тест?

Каждый тест должен что-то проверять. В идеале это “что-то” является “контрактом” метода или процесса. Контракт можно рассматривать как “что делает этот метод?” или, возможно, “что этот метод определенно не делает?”

Пока что элементарные вещи. И все же в своей карьере я сталкивался со множеством модульных тестов, которые, похоже, не подтверждают ничего полезного. Давайте рассмотрим простой гипотетический пример:

Допустим, например, вы пишете модульный тест для контроллера сервлетов, который поддерживает веб-страницу JSP. Когда страница загружается, вы хотите загрузить список объектов из базы данных в сеанс, чтобы они были доступны на странице (возможно, не лучший дизайн, но давайте пока остановимся на этом).

// ClientPageController.java
public String loadPage(HttpSession session, String clientId) throws Exception {
    List customers = customerService.findByClientId(clientId);
    session.setAttribute("customers", customers);
    return "myPage";
}

Пока все довольно просто. Но затем вы видите этот модульный тест:

@Test
public void testLoadPage() throws Exception {
  HttpSession session = mock(HttpSession.class);
  String result = clientPageController.loadPage(session, "my_client_id");
    assertEquals("myPage", result);
}

Здесь чего-то не хватает: частью контракта этого метода является настройка списка клиентов в сеансе HttpSession, и все же в тесте нет ничего, подтверждающего это. Вы проверяете правильность возвращаемого значения и получили некоторое покрытие теста, но в вашем тесте отсутствует важная проверка. Допустим, другой разработчик забредает в эту базу кода и ошибочно фиксирует это изменение:

// ClientPageController.java
public String loadPage(HttpSession session, String clientId) throws Exception {
    // TODO: uncomment when compilation errors are fixed
    // List customers = customerService.findByClientId(clientId);
    // session.setAttribute("customers", customers);
    return "myPage";
}

Приведенный выше модульный тест все еще проходит . Вот в чем проблема! Поэтому вы решаете скорректировать свой модульный тест с помощью проверки:

@Test
public void testLoadPage() throws Exception {
  HttpSession session = mock(HttpSession.class);
  String result = clientPageController.loadPage(session, "my_client_id");
    assertEquals("myPage", result);
    verify(session).setAttribute("customers", anyListOf(Customer.class));
}

У нас дела идут немного лучше, но все еще есть проблема.

Terminologies

Before moving to working examples with Mockito, we should know different types of Test objects that can be created and used in Mockito.

• Dummy: This is an object that is used only for the code to compile and has no business logic associated with it like a parameter passed to a function.
• Fake: This is an object that has an implementation but not ready for production, like H2 in-memory database.
• 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: This is an object that is similar to stubs, but they additionally record how they were executed.

Best practices with Mockito

The common understanding of unit testing is testing the smallest possible part of the software, specifically a method. In reality, we do not test methods; rather, we test a logical unit or the behavior of the system.

Readability

JUnit tests are written to test logical units. A test method name should portray the intention of the test so that a reader can understand what is being tested, such as the condition and the expectation or action.

Good test method names can be:

• should_not_register_a_null_user()
• should_throw_exception_when_a_null_user_is_registered()

Break Everything

An Extreme Programming concept is test everything that could possibly break. This means trying all different combinations of inputs to make sure we don’t miss any combination that can cause the class to generate an error.

Ignore Trivial Tests

Writing trivial JUnits (such that for getter and setter) is mostly a waste of time and money. We don’t have the luxury to write infinite tests as it can eat our development time, application build time, and reduce test maintainability. If we start writing tests for getter/setters, we may miss more useful test cases.

Staying away from debugging

A common practice when we find a bug is to start debugging an application—stop doing this. Rather, add more tests to break the code; this will enrich your test suite and improve the system documentation.

So anyway, before starting to debug, create an (integration) test that reproduces the issue and then debug it. This will narrow down the problem, create a unit test for the lowest possible unit, and keep both the tests for future reference.

A more meaningful example

Following is another application class which uses instance:

package com.logicbig.example;

public class MyProcessor {
  private MyService myService;

  public MyProcessor(MyService myService) {
      this.myService = myService;
  }

  public String process() {
      int returnInteger = myService.doSomething();
      return String.format("My Integer is: " + returnInteger);
  }
}

Let’s mock again to test method:

package com.logicbig.example;

import org.junit.Assert;
import org.junit.Test;
import org.mockito.Mockito;

public class ProcessorTest {

  @Test
  public void processTest() {
      MyService myService = Mockito.mock(MyService.class);
      Mockito.when(myService.doSomething()).thenReturn(10);
      MyProcessor myProcessor = new MyProcessor(myService);
      String returnedValue = myProcessor.process();
      Assert.assertEquals(returnedValue, "My Integer is: 10");
  }
}

D:\mockito-getting-started-creating-mocks>mvn test -Dtest="ProcessorTest" Scanning for projects...  ----< com.logicbig.example:mockito-getting-started-creating-mocks >----- Building mockito-getting-started-creating-mocks 1.0-SNAPSHOT -----------------------------------------------------------------  --- maven-resources-plugin:2.6:resources (default-resources) @ mockito-getting-started-creating-mocks --- Using platform encoding (Cp1252 actually) to copy filtered resources, i.e. build is platform dependent!  --- maven-compiler-plugin:3.8.1:compile (default-compile) @ mockito-getting-started-creating-mocks --- Nothing to compile - all classes are up to date  --- maven-resources-plugin:2.6:testResources (default-testResources) @ mockito-getting-started-creating-mocks --- Using platform encoding (Cp1252 actually) to copy filtered resources, i.e. build is platform dependent!  --- maven-compiler-plugin:3.8.1:testCompile (default-testCompile) @ mockito-getting-started-creating-mocks --- Nothing to compile - all classes are up to date  --- maven-surefire-plugin:2.12.4:test (default-test) @ mockito-getting-started-creating-mocks ---------------------------------------------------------- T E S T S-------------------------------------------------------Running com.logicbig.example.ProcessorTestTests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.694 secResults :Tests run: 1, Failures: 0, Errors: 0, Skipped: 0 ------------------------------------------------------------------------ BUILD SUCCESS ------------------------------------------------------------------------ Total time:  3.798 s Finished at: 2020-04-17T00:20:03-05:00 ------------------------------------------------------------------------

Example — verify() with same arguments

Step 1 − Create an interface called CalculatorService to provide mathematical functions

File: CalculatorService.java

public interface CalculatorService {
   public double add(double input1, double input2);
   public double subtract(double input1, double input2);
   public double multiply(double input1, double input2);
   public double divide(double input1, double input2);
}

Step 2 − Create a JAVA class to represent MathApplication

File: MathApplication.java

public class MathApplication {
   private CalculatorService calcService;

   public void setCalculatorService(CalculatorService calcService){
      this.calcService = calcService;
   }
   
   public double add(double input1, double input2){
      //return calcService.add(input1, input2);
      return input1 + input2;
   }
   
   public double subtract(double input1, double input2){
      return calcService.subtract(input1, input2);
   }
   
   public double multiply(double input1, double input2){
      return calcService.multiply(input1, input2);
   }
   
   public double divide(double input1, double input2){
      return calcService.divide(input1, input2);
   }
}

Step 3 − Test the MathApplication class

Let’s test the MathApplication class, by injecting in it a mock of calculatorService. Mock will be created by Mockito.

File: MathApplicationTester.java

import static org.mockito.Mockito.verify;
import static org.mockito.Mockito.when;

import org.junit.Assert;
import org.junit.Test;
import org.junit.runner.RunWith;
import org.mockito.InjectMocks;
import org.mockito.Mock;
import org.mockito.runners.MockitoJUnitRunner;

// @RunWith attaches a runner with the test class to initialize the test data
@RunWith(MockitoJUnitRunner.class)
public class MathApplicationTester {
	
   //@InjectMocks annotation is used to create and inject the mock object
   @InjectMocks 
   MathApplication mathApplication = new MathApplication();

   //@Mock annotation is used to create the mock object to be injected
   @Mock
   CalculatorService calcService;

   @Test
   public void testAdd(){
      //add the behavior of calc service to add two numbers
      when(calcService.add(10.0,20.0)).thenReturn(30.00);
		
      //test the add functionality
      Assert.assertEquals(calcService.add(10.0, 20.0),30.0,0);

       
      //verify the behavior
      verify(calcService).add(10.0, 20.0);
   }
}

Step 4 − Execute test cases

Create a java class file named TestRunner in C:\> Mockito_WORKSPACE to execute Test case(s).

File: TestRunner.java

import org.junit.runner.JUnitCore;
import org.junit.runner.Result;
import org.junit.runner.notification.Failure;

public class TestRunner {
   public static void main(String[] args) {
      Result result = JUnitCore.runClasses(MathApplicationTester.class);
      
      for (Failure failure : result.getFailures()) {
         System.out.println(failure.toString());
      }
      
      System.out.println(result.wasSuccessful());
   }
}  	

Step 5 − Verify the Result

Compile the classes using javac compiler as follows −

C:\Mockito_WORKSPACE>javac CalculatorService.java MathApplication.
   java MathApplicationTester.java TestRunner.java

Now run the Test Runner to see the result

C:\Mockito_WORKSPACE>java TestRunner

Verify the output.

true