Статьи

Тестирование асинхронных операций весной с JUnit 5 и Byteman

Это уже третья статья, в которой описывается, как тестировать асинхронные операции с каркасом Byteman в приложении с использованием каркаса Spring. Статья посвящена тому, как выполнить такое тестирование с помощью библиотеки JUnit 5.

Предыдущая статья была посвящена тому, как такое тестирование можно выполнить с использованием библиотеки JUnit 4 ( первая статья ) и инфраструктуры Spock ( вторая статья ).

Как и во второй статье, нет необходимости читать предыдущие статьи, потому что все основные части будут повторяться. Тем не менее, я призываю вас прочитать предыдущую статью, касающуюся фреймворка Спока, потому что, на мой взгляд, это хорошая альтернатива для библиотеки JUnit 5.

Хотя весь демонстрационный проект имеет некоторые изменения по сравнению с тем, который использовался в предыдущих статьях (среди прочего, зависимость Spring Boot была обновлена ​​с версии 1.5.3 до 2.2.4), исходный код, используемый для представления тестового примера, представляет собой одно и тоже. Поэтому, если вы уже прочитали предыдущую статью и все еще помните концепцию тестового примера, вы можете быстро перейти к разделу «Тестовый код».

Итак, начнем!

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

Тесты будут выполняться с библиотекой JUnit 5. Если вы не знакомы с JUnit 5, я бы посоветовал вам прочитать  руководство пользователя .

Вот некоторые другие полезные ссылки, которые могут дать вам краткое введение в JUnit 5:

Наша основная тестовая зависимость — библиотека BMUnit. Он является частью проекта Byteman и поддерживает библиотеку JUnit 5. Нам также нужно использовать модуль «utils» maven из проекта расширения BMUnit. 

Byteman  — это инструмент, который внедряет код Java в методы вашего приложения или в методы времени выполнения Java без необходимости перекомпиляции, перепаковки или даже повторного развертывания приложения.

Вам также может понравиться: Использование Byteman для выяснения причин изменения часового пояса на сервере приложений Java.

BMUnit  — это пакет, который упрощает использование Byteman в качестве инструмента тестирования, интегрируя его в две самые популярные среды тестирования Java, JUnit и TestNG.

Расширение  Bmunit  — это небольшой проект на GitHub, содержащий правило JUnit 4, которое позволяет интегрировать его с платформой Byteman и тестами JUnit и Spock. Он также содержит несколько вспомогательных методов в методе «utils», который совместим с версией 4.0.10 проекта Byteman.

Как упоминалось ранее в статье, мы собираемся использовать код из демонстрационного приложения, которое является частью проекта «Bmunit-extension». 

Исходный код можно найти на странице  https://github.com/starnowski/bmunit-extension/tree/master/junit5-spring-demo .

Прецедент

Тестовый пример предполагает, что мы зарегистрировали нового пользователя в нашем приложении (все транзакции были совершены) и отправили ему электронное письмо. Письмо отправляется асинхронно. Теперь приложение содержит несколько тестов, которые показывают, как можно проверить этот случай. Не предполагается, что код, реализованный в демонстрационном приложении для Bmunit-расширения, является единственным или даже лучшим подходом. 

Основная цель этого проекта — показать, как такой случай можно протестировать без изменения производственного кода при использовании Byteman.

В нашем примере нам нужно проверить процесс регистрации пользователя нового приложения. Предположим, что приложение позволяет регистрировать пользователя через REST API. Итак, клиент отправляет запрос с данными пользователя. Затем контроллер обрабатывает запрос. 

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

Весь процесс представлен на диаграмме последовательности ниже.

Пользователь зарегистрироваться рабочий процесс

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

Предположим, что это приемлемо для приложения, в котором нет проблем с доступными потоками.

Реализация для нашего REST Controller:


Джава