Насмешки, шпионы, частичные издевательства и окурки

В этом уроке мы подробно рассмотрим классы и интерфейсы-заглушки, использующие Mockito.

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

• Mock (существительное) — объект, который действует как двойник для другого объекта.
• Mock (глагол) — для создания фиктивного объекта или заглушки метода.
• Шпион (существительное) — объект, который украшает существующий объект и позволяет добавлять методы этого объекта и проверять вызовы этого объекта.
• Spy (глагол) — для создания и использования объекта Spy.
• Заглушка (существительное) — объект, который может предоставлять «стандартные ответы» при вызове его методов.
• Заглушка (глагол) — для создания постоянного ответа.
• Partial Mock, Partial Stub (глагол) — еще один термин для шпиона, некоторые из его методов заглушены.

Технически, Mockito — это скорее Test Spy Framework, чем Mocking Framework, потому что он позволяет нам создавать шпионов и проверять поведение, а также создавать фиктивные объекты с тупым поведением.

Учитывая следующий интерфейс:

И следующий упрощенный класс ‘текстового процессора’ на основе строкового буфера, который его использует:

Мы хотим написать тестовый метод, который будет проверять отсутствие текущего буфера после создания и обрабатывать печать тестовой страницы.

Вот наш тестовый класс:

Мы знаем, что statusAndTest() будет включать в себя вызов printTestPage() Printer и что ссылка на printer не инициализируется, поэтому мы получим NullPointerException если мы выполним этот тест. Чтобы избежать этого, нам просто нужно аннотировать тестовый класс, чтобы JUnit запустил его с Mockito, и аннотировать принтер как макет, чтобы сказать mockito создать макет для него.

Теперь мы можем выполнить наш тест, и Mockito создаст для нас реализацию Printer и назначит ее экземпляр переменной принтера. Мы больше не будем получать исключение NullPointerException.

Но что, если Printer — это класс, который действительно выполняет какую-то работу, например, печатает физическую тестовую страницу? Что если бы мы выбрали @Spy вместо него, вместо создания @Mock ? Помните, что шпион будет вызывать реальные методы шпионящего класса, если только они не заглушены. Мы бы хотели избегать каких-либо реальных действий при вызове метода. Давайте сделаем простую реализацию Printer:

И добавьте его в качестве шпиона в наш тестовый класс и добавьте новый метод для тестирования с его помощью:

Если вы выполните этот тест сейчас, вы увидите следующий вывод на консоли:

Это подтверждает, что наш тестовый пример на самом деле выполняет реальный метод класса SysoutPrinter из-за того, что это шпион, а не мошенник. Если бы класс действительно выполнил реальный физический отпечаток тестовой страницы, это было бы крайне нежелательно!

Когда мы делаем частичную имитацию или Spy, мы можем org.mockito.Mockito.doNothing() метод, чтобы гарантировать, что в нем ничего не происходит, с помощью org.mockito.Mockito.doNothing() .

Давайте добавим следующий импорт и тест:

Обратите внимание на цепочку методов doNothing.when(sysoutPrinter).printTestPage() : это говорит Mockito, что при вызове void метода printTestPage из @Spy sysoutPrinter что настоящий метод не должен выполняться, и вместо этого ничего не следует делать. Теперь, когда мы выполняем этот тест, мы не видим вывод на экран.

Что если мы расширим наш интерфейс Printer, чтобы создать новое исключение PrinterNotConnectedException если физический принтер не подключен. Как мы можем проверить этот сценарий?

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

И измените наш интерфейс, чтобы бросить его:

Нам также нужно изменить StringProcessor чтобы что-то делать с исключением, если оно было StringProcessor . Ради простоты мы просто выбросим исключение обратно в вызывающий класс.

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

Давайте добавим следующий тест:

Здесь мы видим, что мы можем использовать doThrow() чтобы генерировать любые исключения, которые мы хотим. В этом случае мы PrinterNotConnectedException которое удовлетворит наш тест.

Теперь, когда мы узнали, как заглушить пустые методы, давайте посмотрим, как вернуть некоторые данные.

Давайте начнем создавать объект доступа к данным для сохранения и извлечения объектов клиентов из базы данных. Этот DAO будет использовать корпоративный Java- EntityManager под капотом для выполнения реальных взаимодействий с БД.

Чтобы использовать EntityManager мы будем использовать реализацию JPA 2.0 в Hibernate, добавив следующую зависимость в ваш файл pom.xml:

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

Теперь мы создадим скелет DAO, который использует @PersistenceContext для настройки @PersistenceContext EntityManager . Нам не нужно беспокоиться об использовании Java Persistence Architecture (JPA) или о том, как она работает — мы будем использовать Mockito, чтобы полностью обойти ее, но это служит хорошим примером реального применения Mockito в действии.

Мы будем добавлять базовые функциональные возможности получения и обновления в нашу DAO и тестировать ее с помощью Mockito.

Начнем с метода Retrieve — мы передадим ID и вернем соответствующего Клиента из БД, если они существуют.

Здесь мы используем Java Optional чтобы избежать необходимости делать нулевые проверки результатов.

Теперь мы можем добавить тесты для тестирования этого метода, когда клиент найден, а клиент не найден — мы заглушим метод find() для возврата соответствующего Optional в каждом случае, используя методы org.mockito.Mockito.when и затем thenReturn()

Давайте создадим наш класс Test следующим образом ( import static org.mockito.Mockito.*; Для методов Mockito):

Мы видим обычный шаблон для включения mockito, насмешки над EntityManger и введения его в тестируемый класс. Давайте посмотрим на метод испытаний.

Первые строки включают создание Customer с известными ожидаемыми значениями, затем мы видим вызов Mockito, который сообщает ему, чтобы он возвращал этого клиента, когда вызывается метод EntityManager.find() с конкретными входными параметрами, которые мы ему передаем. Затем мы выполняем фактическое выполнение метода findById() и группы утверждений, чтобы гарантировать получение ожидаемых значений.

Давайте рассмотрим вызов Mockito:

Это демонстрирует мощный, элегантный синтаксис Mockito. Это почти читается как обычный английский. Когда метод find() объекта mockEntityManager вызывается с конкретными входными данными Customer.class и expectedId mockEntityManager , тогда возвращается объект expectedCustomer объект.

Если вы вызываете Mock с параметрами, которые вы не указали, чтобы ожидать, то он просто вернет null, как показывает следующий тест:

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

Вы можете даже соединить цепочку возвратов, чтобы заставить макет делать что-то другое в каждом вызове. Обратите внимание, что если вы вызываете макет больше раз, чем используете заглушку, он будет продолжать вести себя в соответствии с последней заглушкой навсегда.

Обратите внимание, что мы ввели один и тот же идентификатор в оба вызова, другое поведение поддерживается вторым theReturn() , это работает только потому, что часть заглушки when() явно ожидает и ввод в поле theReturn() , если мы передали expectedId2 мы получил бы нулевой ответ от макета из-за того, что это не ожидаемое значение в заглушке.

Теперь давайте проверим случай, когда клиент отсутствует.

Здесь мы можем видеть, что мы используем тот же синтаксис, но на этот раз используем его для возврата null.

Mockito позволяет вам использовать VarArgs в thenReturn для thenReturn последовательных вызовов, поэтому, если мы захотим, мы можем свернуть предыдущие два теста в один следующим образом:

Что если наш метод find вызывает исключение из-за некоторой проблемы с сохранением? Давайте проверим это!

Мы использовали метод thenThrow() чтобы thenThrow() наше исключение. Сравните этот синтаксис с нашим использованием doThrow() когда doThrow() методы. Это два похожих, но разных метода — thenThrow() не будет работать с методами void.

Выше мы видели, что создали клиента с определенными ожидаемыми значениями. Если мы хотим создать несколько известных тестовых пользователей и вернуть им базу с их идентификаторами, мы могли бы использовать Answer который мы могли бы вернуть из наших вызовов when() . Answer — это универсальный тип, предоставляемый Mockito для предоставления «стандартных ответов». Его метод answer() принимает объект InvocationOnMock который содержит определенную информацию о текущем вызове фиктивного метода.

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

Сначала 3 клиента добавляются как частные члены тестового класса.

Затем добавьте частный метод setupCustomers для их инициализации и вызовите его из метода @Before .

И теперь мы можем создать Answer для возврата соответствующего Customer на основе идентификатора, который был передан методу find() переданному в mock EntityManager во время выполнения.

Мы можем видеть, что мы используем InvocationOnMock чтобы получить аргументы, которые были переданы в вызов метода Mock. Мы знаем, что вторым аргументом является идентификатор, поэтому мы можем прочитать его и определить подходящего клиента для возврата. Имя ответа withCustomerById будет соответствовать нашему withCustomerById синтаксису позже.

Теперь давайте напишем тест, который демонстрирует этот ответ в действии.

Давайте посмотрим на строку окурок в деталях.

Здесь мы видим пару новых вещей. Во-первых, вместо того, чтобы делать when().thenReturn() мы делаем when().thenAnswer() и предоставляем наш ответ withCustomerById в качестве ответа, который будет дан. Во-вторых, мы не используем действительное значение для идентификатора, переданного в mockEntityManager.find() вместо этого мы используем статический org.mockito.Matchers.anyLong() . Это Matcher и он используется для того, чтобы Mockito запустил Ответ, не проверяя, передано ли определенное значение Long. Matchers позволяют игнорировать параметры ложного вызова и вместо этого концентрируются только на возвращаемом значении.

Мы также украсили Customer.class с помощью eq() Matcher — это связано с тем, что вы не можете смешивать реальные значения и соответствия в вызовах метода Mock, вы должны либо иметь все параметры как Matchers, либо все параметры как реальные значения. eq() предоставляет Matcher, который соответствует только тогда, когда параметр времени выполнения равен указанному параметру в заглушке. Это позволяет нам возвращать ответ только в том случае, если тип входного класса имеет тип Customer.class без указания конкретного идентификатора.

Все это означает, что три вызова mockEntityManager.find() с разными идентификаторами приводят к получению одного и того же Ответа, и, поскольку мы закодировали Ответ, чтобы ответить соответствующими объектами Customer для разных идентификаторов, мы успешно смоделировали EntityManager способный имитировать реалистичное поведение.

Возможно, вы заметили, что в наших модульных тестах мы приняли соглашение о разбиении теста на 3 части — // Дано, // Когда и // Затем. Это соглашение называется Behavior Driven Development и является очень логичным способом разработки модульных тестов.

• / / Данный этап установки, на котором мы инициализируем данные и заглушку классов. Это то же самое, что заявить «учитывая следующие начальные условия».
• // Когда это фаза выполнения, где мы выполняем тестируемый метод и фиксируем все возвращаемые объекты.
• // Затем наступает этап проверки, на котором мы размещаем логику утверждения, которая проверяет, ведет ли метод себя так, как ожидается.

Mockito поддерживает BDD из коробки в классе org.mockito.BDDMockito . Он заменяет обычные методы- thenReturn() — when() , thenReturn() , thenThrow() , thenAnswer() т. Д. На thenAnswer() BDD — willReturn() , willThrow() , willAnswer() , willAnswer() . Это позволяет нам избегать использования when() в разделе // Given, поскольку это может сбивать с толку.

Поскольку в наших тестах мы используем соглашение BDD, мы также будем использовать методы, предоставляемые BDDMockito.

Позволяет переписать finding_existing_customer_should_return_customer() с использованием синтаксиса BDDMockito.

Логика теста не изменилась, она просто более читабельна в форме BDD.

Если вы хотите избежать импорта org.mockito.Mockito.* т org.mockito.Mockito.* Д., Чтобы вручную добавить статический импорт для различных статических методов org.mockito.Mockito.* и перейдите к Java / Editor / Content Assist / Favorites в левой навигационной панели. После этого добавьте следующее как «Новый тип…» согласно рисунку 1.

• org.mockito.Mockito
• org.mockito.Matchers
• org.mockito.BDDMockito

Это добавит статические методы Mockito в Eclipse Content Assist, что позволит вам автоматически заполнять и импортировать их по мере их использования.

Теперь мы рассмотрим использование нескольких макетов в комбинации. Давайте добавим метод в нашу DAO, чтобы получить список всех доступных клиентов.

Здесь мы видим, что метод createQuery() EntityManager возвращает типизированный типизированный TypedQuery . Он принимает в качестве параметров строку SQL и класс, который является типом возвращаемого значения. Сам TypedQuery предоставляет несколько методов, включая List getResultList() который можно использовать для выполнения запросов, которые возвращают несколько значений, таких как наш select * from CUSTOMER запроса select * from CUSTOMER выше.

Чтобы написать тест для этого метода, мы хотим создать Mock of TypedQuery .

Теперь мы можем заглушить этот фиктивный запрос, чтобы получить список известных клиентов. Давайте создадим ответ, чтобы сделать это, и повторно использовать известных клиентов, которых мы создали ранее. Возможно, вы заметили, что Ответ — это функциональный интерфейс, имеющий только один метод. Мы используем Java 8, поэтому мы можем создать лямбда-выражение для представления нашего встроенного ответа, а не анонимного внутреннего класса, как мы делали в предыдущем примере ответа.

Конечно, мы могли бы также кодировать заглушку как

что демонстрирует гибкость Mockito — всегда есть несколько разных способов сделать одно и то же.

Теперь мы остановили поведение ложного TypedQuery мы можем TypedQuery ложное EntityManager чтобы оно возвращалось по запросу. Вместо того, чтобы anyString() SQL в наш тестовый пример, мы просто будем использовать Matcher anyString() чтобы запустить mock createQuery() , конечно же, мы также createQuery() параметр класса createQuery() eq() .

Полный тест выглядит так:

Давайте добавим метод Update() DAO:

Теперь посмотрим, сможете ли вы создать для него тест. Возможное решение было написано в примере проекта кода, включенного в это руководство. Помните, что есть много способов сделать то же самое в Mockito, посмотрите, можете ли вы подумать о некоторых из них!

Естественное поведение Mocktio заключается в использовании метода equals() объекта, который передается в качестве параметра, чтобы увидеть, применимо ли определенное поведение с заглушкой. Однако можно избежать использования реальных объектов и переменных при создании заглушки, если нам неважно, что это за значения. Мы делаем это с помощью Mockito Argument Matchers

Мы уже видели несколько работающих сопоставителей аргументов Mockito: anyLong() , anyString() и eq . Мы используем эти средства сопоставления, когда нам не особенно важны входные данные для Mock, нас интересует только кодирование поведения возврата, и мы хотим, чтобы он вел себя одинаково при любых условиях.

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

Все org.mockito.ArgumentMatcher сопоставления аргументов расширяют org.mockito.ArgumentMatcher а Mockito включает в себя библиотеку готовых сопоставителей аргументов, доступ к которым можно получить через статические методы org.mockito.Matchers , чтобы использовать их, просто импортировав org.mockito.Matchers.* ;

Вы можете посмотреть на javadoc для org.mockito.Matchers чтобы увидеть все Matchers, которые предоставляет Mockito, в то время как следующий тестовый класс демонстрирует использование некоторых из них:

Также возможно создавать свои собственные Matchers, расширяя org.mockito.ArgumentMatcher . Давайте создадим совпадение, которое срабатывает, если List содержит определенный элемент. Мы также создадим статический удобный метод для создания Matcher, который использует argThat для преобразования Matcher в List для использования в вызове stubbing. Мы будем реализовывать метод matches() чтобы вызывать метод содержимого объекта List для выполнения нашей фактической проверки содержимого.

А теперь тест, чтобы продемонстрировать наш новый Matcher в действии!

В качестве упражнения попробуйте написать свой собственный Matcher, который будет соответствовать, если карта содержит определенную пару ключ / значение.

Как мы видели ранее, можно частично @Spy класс с @Spy аннотации @Spy . Частичная заглушка позволяет нам использовать реальный класс в наших тестах и ​​заглушать только то поведение, которое нас интересует.Рекомендации Mockito говорят нам, что шпионов следует использовать осторожно и время от времени, обычно при работе с устаревшим кодом. Лучшей практикой является не использование Spy для частичной насмешки над тестируемым классом, а частичная имитация зависимостей. Тестируемый класс всегда должен быть реальным объектом.

Давайте представим, что мы имеем дело с классом обработки изображений, который работает с java.awt.BufferedImage. Этот класс возьмет в свой BufferedImageконструктор и предоставит метод, чтобы заполнить изображение случайными цветными вертикальными полосами и вернуть миниатюру изображения, основываясь на входной высоте миниатюры.

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

Мы видим много взаимодействий с BufferedImage, большинство из которых полностью внутренние или случайные. В конечном итоге, когда мы хотим проверить поведение нашего метода, для нас важен первый вызов getScaledInstance()— наш класс работает, если возвращаемое значение нашего метода — это объект, который возвращается из getScaledInstance (). Это поведение BufferedImage, которое нам важно заглушить. Проблема, с которой мы сталкиваемся, состоит в том, что существует множество других вызовов методов BufferedImages. Мы не особо заботимся о возвращаемых значениях этих методов с точки зрения тестирования, но если мы не закодируем поведение для них, они как-то вызовут NullPointerExceptions и, возможно, другое нежелательное поведение.

Чтобы обойти эту проблему, мы создадим Spy для BufferedImage и только заглушим getScaledInstance()интересующий нас метод.

Давайте создадим пустой тестовый класс с тестируемым классом и созданным Spy, а также макет для возвращенного эскиза.

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

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

Обычно это лучший способ заглушки для шпиона, однако в этом случае есть проблема — imageSpy является реальным BufferedImage, а передаваемый вызов заглушки given()является реальным вызовом метода, который фактически выполняется, когда операция заглушки выполняется JVM. getScaledInstanceтребует, чтобы ширина и высота были ненулевыми, поэтому этот вызов приведет к IllegalArgumentExceptionброску.

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

Этот тест выполняется успешно и выдает следующий вывод на консоль

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

Но что, если мы захотим продолжить использование Argument Matchers? Можно использовать doReturn()метод (обычно используемый для void-методов, если вы помните), чтобы заглушить getScaledInstance()метод без его фактического вызова во время заглушки.

Это дает следующий вывод:

Вы можете видеть, что тип времени выполнения микроизображения теперь является реализацией Mock, созданной Mockito. Это так, потому что оба вызова getScaledInstanceсовпадают с аргументами заглушки и, таким образом, миниатюра макета возвращается из обоих вызовов.

Существует способ гарантировать, что реальный метод Spy вызывается во втором случае, это с помощью doCallRealMethod()метода Mockito. Как обычно, Mockito позволяет вам связывать воедино методы-заглушки, чтобы кодировать различное поведение для последовательных вызовов метода-заглушки, которые соответствуют аргументам-заглушкам.

Что дает следующий вывод

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

Javadoc для Mockito является хорошим источником информации о методах Stubbing и особенно о ArgumentMatchers, которые Mockito предоставляет «из коробки».

Мы подробно рассмотрели поведение заглушки, и в следующем уроке мы рассмотрим проверку поведения Mocks с использованием инфраструктуры проверки Mockito.