Mockito и Behavior Driven Development

20.12.2014 / 19:42 от Freddy

Java test, bdd

Когда разработчик только начинает изучать принципы тестирования, он, как правило, знакомится в первую очередь с тестированием, основывающемся на проверке данных. То есть, чтобы протестировать функцию сложения чисел разработчик пишет, например, такой тест: “Заданы числа 2 и 3, в качестве результата ожидается 5”, и по тому, выполнилось ли это утверждение или нет, он делает вывод о верной или неверной реализации тестируемой функции.
Такой подход хорошо работает, когда код достаточно прост, результат предсказуем, и его проверка не займёт относительно много времени. Но на практике часто функции сложные, тяжело покрыть тестами каждый возможный исход, либо подготовка исходных или проверка конечных данных для теста занимает много времени. Можно, конечно, подумать: “Это сложно тестировать автоматически, поэтому пусть тестировщик придумает тесты и проверяет их вручную”. Но это не решение проблемы, потому что проект может собираться несколько раз в день, а ручное тестирование – самое затратное по времени, в чём наверняка каждый из вас убеждался, перезапуская в n-цатый раз эмулятор с мидлетом или обновляя страницу в браузере после очередной правки в коде сервера. После отладки в несколько часов (а так бывает, когда ещё и баг воспроизводится не всегда, а при некоторых условиях) возникает вопрос: “А можно ли сделать так, чтобы потратить время на написание тестов нетривиальной функции, которые будут выполняться автоматически и занимать меньше времени?”. Часто ответ здесь: “Да, можно!”, если тестировать не только данные, но и поведение тестируемого объекта. И далее мы переходим к принципу тестирования, который фокусируется на том, как программа функционирует, а не что она производит в конечном итоге. Этот принцип называется Behavior Driven Development.
Предположим, что мы написали некоторый модуль, подумали над тем, как он должен вести себя в той или иной ситуации. Как же нам отследить при тестировании как модуль ведёт себя в реальности и соответствует ли это нашим ожиданиям? Первое, что приходит на ум - логирование:

[копировать] [скачать]
public void testingFunction() {
    if(condition) {
        frame.repaint();
        log.debug("frame repaint");
        if(blablabla) {
            frame.getContentPane().removeAll();
            log.debug("Remove widgets. Logs! Need more LO-O-O-OGS!");
        }
    } else {
        log.debug("condition false. Nothing to do");
    }

Минусы тут очевидны: во-первых, "тестируя" таким образом код, мы вторгаемся в код, вставляя вызовы логгера, а хорошие тесты не должны модифицировать тот код, который они проверяют. Во-вторых, такие логи тяжело читать, да и разобрать их автоматически не так просто, а в третьих, к счастью, нет разработчиков, которые пишут "тесты" подобным образом.
Хорошо, логирование на каждый чих нам не подходит, но как нам иначе выяснить, как ведёт себя тестируемый код? В этом нам поможет библиотека Mockito, но сначала нужно понять, что такое mock-объекты, и для чего они нужны в тестировании.

Рассмотрим пример с таким известным интерфейсом как List. У него есть методы, которые выполняют действия, как это описано в документации. Т. е. метод add добавляет объект в список и возвращает true, если список изменился, или false, если реализация списка не допускает хранения дубликатов, а такой объект в списке уже есть; есть метод size, который возвращает размер списка; есть метод get(int index), который возвращает объект по данному индексу или бросает исключение, если значение индекса некорректно. Mock-объект - это объект, который имеет тот же интерфейс, что и реальный объект, но реализация его - "тупая", то есть mock-объект при вызове методов add, size, get и т. д. вернёт значения по умолчанию, а конкретнее:
false для add
0 для size
null для get
Отмечу ещё, что в случае, если метод реального объекта возвращает какую-либо коллекцию, то метод mock-объекта вернёт пустую коллекцию.

Зачем нужны mock-объекты, если они такие "тупые"? Дело в том, что mock-объект можно "спросить": "Ответь, был ли вызван такой-то метод да ещё и с такими-то параметрами?". Наш первый пример:

[копировать] [скачать]
import static org.mockito.Mockito.*; 
 
List mockedList = mock(List.class); //создали mock-объект для класса List
 
mockedList.add("one"); //вызвали у него метод add с параметром "one"
mockedList.clear(); //вызвали у него метод clear
 
verify(mockedList).add("one"); //проверили, что метод add был вызван, да ещё и с уточнением, что параметром был именно "add"
verify(mockedList).clear(); //проверили, что метод clear был вызван

В дальнейшем строки импорта я буду опускать для краткости.

Но mock-объекты полезны не только этим. Пожалуй, самая важная возможность - mock можно научить специфичному поведению. Как уже выше отмечалось, созданный mock при вызове методов возвращает значения по умолчанию, а теперь давайте научим его дпугим действиям:

[копировать] [скачать]
List mockedList = mock(ArrayList.class); //можно сказать Mockito создать mock конкретного класса, не только интерфейса
 
when(mockedList.get(0)).thenReturn("first"); //здесь мы задаём mock'у поведение: "Если будет вызван метод get с параметром 0, то верни значение "first" (а не null, как по умолчанию)"
when(mockedList.get(1)).thenThrow(new RuntimeException()); //здесь мы задаём mock'у поведение: "Если будет вызван метод get с параметром 1, то брось исключение"
 
System.out.println(mockedList.get(0)); //посмотрим, что выведет в консоль, если вызвать у mock метод get(0)
System.out.println(mockedList.get(1)); //а эта строка должна бросить исключение
System.out.println(mockedList.get(999)); //здесь будет выведено null, потому что мы не задали поведение для get(999) и будет выполнено действие по умолчанию
 
verify(mockedList).get(0); //можно так же проверить, что был вызов метода, для которого мы определили другое поведение.

Когда задаётся поведение для mock, можно указывать не только определённые параметры, но и использовать так называемые Argument matchers:

[копировать] [скачать]
private ArgumentMatcher isValid() {
        return new ArgumentMatcher() {
 
            @Override
            public boolean matches(Object element) {
                //Implementation
            }
        };
}
 
...
 
when(mockedList.get(anyInt())).thenReturn("element"); //задаём поведение: "если будет вызван метод get с любым параметром типа int, верни "element" "
when(mockedList.contains(argThat(isValid()))).thenReturn(true); //задаём поведение: "если будет вызван метод contains c параметром, который допустим для нашего собственного ArgumentMatcher, то вернуть true"
 
System.out.println(mockedList.get(999)); //будет выведено "element"
 
verify(mockedList).get(anyInt()); //ArgumentMatcher можно использовать так же при проверке вызова методов

Замечание: если использовать ArgumentMatcher, то все параметры должны предоставляться с их помощью:

[копировать] [скачать]
verify(mockedList).set(anyInt(), "replaced"); //неправильно
verify(mockedList).set(anyInt(), eq("replaced")); //правильно

Можно так же проверить сколько раз вызывался метод:

[копировать] [скачать]
mockedList.add("once");
 
mockedList.add("twice");
mockedList.add("twice");
 
mockedList.add("three times");
mockedList.add("three times");
mockedList.add("three times");
 
verify(mockedList).add("once"); //проверяем, что метод add с параметром "once" вызывался один раз
verify(mockedList, times(1)).add("once"); //то же самое, но в другой записи
 
verify(mockedList, times(2)).add("twice"); //проверяем, что метод add с параметром "twice" вызывался 2 раза
verify(mockedList, times(3)).add("three times"); //проверяем, что метод add с параметром "three times" вызывался 3 раза
 
verify(mockedList, never()).add("never happened"); //проверяем, что метод add с параметром "never happened" не вызывался никогда, можно использовать вместо never() times(0)
 
verify(mockedList, atLeastOnce()).add("three times"); //проверяем, что метод add с параметром "three times" вызывался не менее одного раза
verify(mockedList, atLeast(2)).add("five times");  //проверяем, что метод add с параметром "five times" вызывался не менее 2 раз
verify(mockedList, atMost(5)).add("three times"); //проверяем, что метод add с параметром "three times" вызывался не более 5 раз

Как было показано выше, в первых примерах, можно заставить mock бросить исключение:

[копировать] [скачать]
doThrow(new RuntimeException()).when(mockedList).clear(); //эта запись используется для void методов
mockedList.clear();

Можно проверять порядок вызова методов:

[копировать] [скачать]
List mockedList = mock(List.class);
 
mockedList.add("first");
mockedList.add("second");
 
InOrder inOrder = inOrder(mockedList);
 
inOrder.verify(mockedList).add("first");
inOrder.verify(mockedList).add("second");

Можно проверить, что никакие методы mock'а не вызывались:

verifyZeroInteractions(mockedList);

Можно проверить, что после некоторых действий никакие методы mock'а больше не вызывались:

[копировать] [скачать]
verify(mockedList).add("one"); //проверили, что вызывался add("one")
verifyNoMoreInteractions(mockedList); //и больше ничего

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

[копировать] [скачать]
when(mockedList.get(0)) //поведение: когда 
    .thenThrow(new RuntimeException()) //в первый раз брось исключение
    .thenReturn("foo"); // во второй и последующие разы верни объект "foo"
 
mockedList.get(0); //будет брошено исключение
 
System.out.println(mockedList.get(0)); //в консоль будет выведено "foo"
System.out.println(mockedList.get(0)); //в консоль снова будет выведено "foo"

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

[копировать] [скачать]
List list = new LinkedList(); // создаём реальный объект
List spy = spy(list); //создаём его mock, но который будет вести себя по умолчанию в точности так, как ведёт себя реальный объект
 
when(spy.size()).thenReturn(100); //но такой mock при желании тоже можно переобучить другому поведению
//давайте немного поэкспериментируем
spy.add("one");
spy.add("two");
 
System.out.println(spy.get(0)); //в консоль будет выведено "one"
 
System.out.println(spy.size()); //в консоль будет выведено 100, а не 2, так как мы переобучили mock.size()
 
verify(spy).add("one"); //проверять вызовы методов таких mock'ов так же легко, как и обычных
verify(spy).add("two");

Но переопределение поведения некоторых методов придётся записывать иначе:

[копировать] [скачать]
List list = new LinkedList();
List spy = spy(list);
 
when(spy.get(0)).thenReturn("foo"); //так нельзя: будет вызван реальный метод get(0), поэтому здесь будет брошено исключение IndexOutOfBoundsException, так как список пустой 
 
doReturn("foo").when(spy).get(0); //писать надо так

На этом закончим разбор возможностей Mockito, поскольку остальные возможности были введены позже, и могут отсутствовать, если вы используете старую версию библиотеки, из новых возможностей стоит упомянуть проверку с таймаутом:

verify(mock, timeout(100).times(1)).someMethod();

что на практике помогает тестировать асинхронный код.

Как вы могли видеть, в примерах они создаются с помощью методов mock() и spy(). Mockito позволяет создавать их так же с помощью аннотаций:

@Mock
private List mockList;
@Spy
private List spyList;

При тестировании mock'и можно внедрять в тестируемый объект:

[копировать] [скачать]
public class MyCoolObject {
 
    private List list;
    private Map map;
}
...
public class MyCoolObjectTest {
 
    @Mock
    private List mockList;
 
    @Mock
    private Map mockMap;
 
    @InjectMocks //указываем, куда внедрять mock'и
    private MyCoolObject object;
 
    @Before
    public void setUp() {
 
    }
}

Есть несколько способов начать процесс внедрения:
1. В методе setUp вызвать:

MockitoAnnotations.initMocks(this);

2. Указать над объявлением тестового класса аннотацию @MockitoJUnitRunner
3. Добавить в тестовый класс поле (требуется версия JUnit не ниже 4.9):

@Rule
public MockitoJUnitRule mockitoJUnitRule = new MockitoJUnitRule(this);

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

Замечания:
1. Mockito не умеет работать с private/final/static методами, конструкторами и final классами. Если без этого при написании тестов совсем никак не обойтись, то можно использовать библиотеку PowerMock, которая является надстройкой над Mockito.

И в заключение пример:
Предположим, что мы пишем сервис, который принимает некие сообщения. Сообщения состоят из двух полей: prefix и body. Body - это непосредственно само сообщение, а значение prefix говорит, что сервис должен сделать с сообщением: если префикс - "mail", то сообщение нужно отправить по электронной почте, если префикс - "database", то сообщение нужно сохранить в базу данных, если сообщение имеет другой префикс, то его нужно записать в лог.
Message:

[копировать] [скачать]
package org.mockitoexample;
 
/**
 *
 * @author Igor
 */
public class Message {
 
    private final String prefix;
    private final String body;
 
    public Message(String prefix, String body) {
        this.prefix = prefix;
        this.body = body;
    }
 
    public String getPrefix() {
        return prefix;
    }
 
    public String getBody() {
        return body;
    }
 
    @Override
    public String toString() {
        return "Message{" + "prefix=" + prefix + ", body=" + body + '}';
    }
 
}

MessageHandler:

[копировать] [скачать]
package org.mockitoexample;
 
/**
 *
 * @author Igor
 */
public interface MessageHandler {
 
    void handle(Message msg);
 
}

MailSender:

[копировать] [скачать]
package org.mockitoexample;
 
/**
 *
 * @author Igor
 */
public class MailSender implements MessageHandler {
 
    @Override
    public void handle(Message msg) {
        //Implementation
    }
 
}

MessageDAO:

[копировать] [скачать]
package org.mockitoexample;
 
/**
 *
 * @author Igor
 */
public class MessageDAO implements MessageHandler {
 
    @Override
    public void handle(Message msg) {
        //Implementation
    }
 
}

MessageLogger:

[копировать] [скачать]
package org.mockitoexample;
 
/**
 *
 * @author Igor
 */
public class MessageLogger implements MessageHandler {
 
    @Override
    public void handle(Message msg) {
        //Implementation
    }
 
}

MessageService:

[копировать] [скачать]
package org.mockitoexample;
 
import java.util.HashMap;
import java.util.Map;
 
/**
 *
 * @author Igor
 */
public class MessageService {
 
    private MessageLogger logger;
 
    private Map<String, MessageHandler> handlers;
 
    public MessageService() {
        handlers = new HashMap<>(2);
        handlers.put("mail", new MailSender());
        handlers.put("database", new MessageDAO());
        logger = new MessageLogger();
    }
 
    public void handle(Message msg) {
        if (!isMessageValid(msg)) {
            throw new IllegalArgumentException("bad message: " + msg.toString());
        }
        MessageHandler handler = handlers.get(msg.getPrefix());
        if (handler == null) {
            logger.handle(msg);
        } else {
            handler.handle(msg);
        }
    }
 
    private boolean isMessageValid(Message msg) {
        if (msg == null) {
            return false;
        }
        return !("".equals(msg.getPrefix().trim())
            || "".equals(msg.getBody().trim()));
    }
}

Нам нужно потестировать MessageService. Думаем над возможными сценариями:
1. У сообщения нет префикса или он пустой. В этом случае должно быть брошено исключение;
2. У сообщения нет тела или оно пустое. В этом случае должно быть брошено исключение;
3. Сообщение валидное и имеет префикс "mail". В этом случае его должен обработать MailSender;
4. Сообщение валидное и имеет префикс "database". В этом случае его должен обработать MessageDAO;
5. Сообщение валидное и имеет префикс, отличный от "mail" и "database". В этом случае его должен обработать MessageLogger;
Если бы мы руководствовались принципами Data Driven Development, то планы последних тестов были бы примерно такими:
1. Перед тестом зафиксировать данные (убедиться, что база данных (почтовый ящик или файл логов тоже) пуста, если нет, то очистить её либо запомнить состояние до теста);
2. Подготовить сообщение для каждого теста;
3. Прогнать тест;
4. Сравнить состояние данных в БД (почтовом ящике, файле с логами) с исходным;
5. Подчистить за собой ресурсы, откатить изменения в БД (почтовом ящике, файле с логами);
Очевидно, что пункты 1, 2, 4, 5 будут занимать больше времени, чем сам тест. А если у нас не пять тестов для одной-то функции, а мы имеем дело с тестированием частей большой системы? Количество тестов может быть несколько десятков, а то и сотен, в зависимости от фантазии при разработке сценариев тестов.
Но раз уж мы решили убедиться в преимуществах Behavior Driven Development, самое время начать писать тесты в этом стиле:

[копировать] [скачать]
package org.mockitoexample;
 
import java.util.Map;
import org.junit.Before;
import org.junit.Test;
import org.junit.runner.RunWith;
import org.mockito.InjectMocks;
import org.mockito.Matchers;
import org.mockito.Mock;
import static org.mockito.Mockito.never;
import static org.mockito.Mockito.verify;
import static org.mockito.Mockito.verifyZeroInteractions;
import static org.mockito.Mockito.when;
import org.mockito.runners.MockitoJUnitRunner;
 
/**
 *
 * @author Igor
 */
@RunWith(MockitoJUnitRunner.class) //необходимо для внедрения mock'ов
public class MessageServiceTest {
 
    //создаём mock'и наших классов, обрабатывающих сообщения
    @Mock
    private MailSender mailSender;
 
    @Mock
    private MessageDAO messageDAO;
 
    @Mock
    private MessageLogger logger;
 
    //также создаём mock для Map handlers (см. поле в MessageService)
    @Mock
    private Map<String, MessageHandler> handlers;
 
    //сюда будем внедрять наши mock'и
    @InjectMocks
    private MessageService service;
 
    public MessageServiceTest() {
    }
 
    @Before
    public void setUp() {
        //обучаем наш mock некоторым действиям, в конструкторе MessageService реальный объект Map заполняется реальными объектами, а мы научим его "отвечать" mock'ами обработчиками сообщений
        when(handlers.get("mail")).thenReturn(mailSender);
        when(handlers.get("database")).thenReturn(messageDAO);
    }
 
    //первый сценарий. Здесь не нужны даже проверки из Mockito, JUnit справится
    @Test(expected = IllegalArgumentException.class)
    public void messageWithInvalidPrefixShouldRaiseException() {
        Message msg = new Message(" ", "body");
        service.handle(msg);
    }
 
    //второй сценарий. Как и в первом тесте - проверки Mockito не нужны
    @Test(expected = IllegalArgumentException.class)
    public void messageWithInvalidBodyShouldRaiseException() {
        Message msg = new Message("mail", "");
        service.handle(msg);
    }
 
    //третий сценарий. Уже интереснее
    @Test
    public void messageWithMailPrefixShouldBeSentBymail() {
        Message msg = new Message("mail", "body");
        service.handle(msg);
 
        verify(mailSender).handle(msg); //проверяем, что сообщение обработал mailSender
        //а messageDAO и logger ничего не обработали
        verify(messageDAO, never()).handle(Matchers.any(Message.class));
        verify(logger, never()).handle(Matchers.any(Message.class));
    }
 
    //четвёртый сценарий
    @Test
    public void messageWithDatabasePrefixShouldBeSavedToDatabase() {
        Message msg = new Message("database", "body");
        service.handle(msg);
 
        verify(messageDAO).handle(msg); //проверяем, что сообщение обработал messageDAO
        verifyZeroInteractions(mailSender, logger); //более краткая запись, в предыдущем тесте можно было сделать так же
    }
 
    //пятый сценарий
    @Test
    public void messageWithValidPrefixShouldBeLoggedIfThereIsNotSpecifiedHandlers() {
        Message msg = new Message("title", "body");
        service.handle(msg);
 
        verify(messageDAO).handle(msg);
        verifyZeroInteractions(mailSender, logger);
    }
 
}

Как видите, система покрыта тестами, и, чтобы убедиться в её полной работоспособности, достаточно будет написать только по одному тесту для каждого обработчика, чтобы убедиться, что сообщение отсылается по email, сохраняется в базу и пишется в лог. Но это уже совсем другая история.

MockitoExample.zip