Привет! Меня зовут Наталья, я SDET-специалист в компании SimbirSoft.
Эта статья посвящается тем, кто еще ни разу не работал с моками и хочет на простом примере попробовать их на практике.
Коротко о том, что это такое
Mock-объекты (тестовые дублеры) — это объекты, предназначенные для симуляции поведения реальных объектов во время тестирования.
Тестовые дублеры позволяют:
- зафиксировать тестовое окружение, имитируя неважные, нереализованные, нестабильные или медленные внешние объекты (например, БД или сервер),
- совершать проверки своих вызовов (обращений к функциям, свойствам).
Самая популярная классификация включает 5 видов тестовых дублеров, различных по своим свойствам: Dummy (пустышка), Fake (фейк), Stub (стаб), Spy (шпион) и, собственно, Mock (мок). Их можно разделить на два типа: моки (mock, spy) и стабы (stub, dummy, fake). Первые работают с исходящими взаимодействиями (например, отправка электронной почты), а вторые с входящими (например, чтение данных из очереди). Почитать об этих и остальных видах дублеров можно в первоисточнике, а также тут или тут, или на Habr.
Для чего нужны моки
Применение моков может решить несколько проблем:
— атомарность теста и его информативность (при падении теста не придется решать вопросы локализации дефекта, поскольку баг гнездится исключительно в тестируемом объекте, а не в тех системах, которые он использует);
— снижение его хрупкости вследствие зависимости от сторонних систем (внешних, не тестируемых сервисов и БД);
— позволит создавать необходимые тестовые условия, например, ошибки;
— дополнительным положительным эффектом является снижение времени прохождения теста.
Мокирование широко применяется в тестировании. Postman (как и SoapUi) предоставляют возможность создать мок-сервер и воспользоваться благами мокирования при мануальном тестировании бэкенда. Посмотреть можно на русском языке YouTube и здесь YouTube, либо в исходнике здесь Postman Learning Center и здесь SoapUI.
Мокирование в автоматизации тестирования
Но, как специалисты, умеющие писать код, мы будем делать это на более продвинутом уровне. И для нас уже созданы необходимые фреймворки.
Ниже представлен рейтинг опенсорсных java-mocking проектов:
Как видите, выбор есть.
А теперь при помощи комбинации WireMock (№2 в нашем рейтинге), JUnit 5 и Rest-Assured напишем наш «Hello, world!».
Ниже предлагается авторский перевод фрагментов статьи Onur Baskirt (с оригиналом можно ознакомиться здесь), который нам в этом поможет.
В этой статье мы кратко продемонстрируем связки WireMock и JUnit 5. Мы можем создавать моки и стабы как на автономном сервере (standalone), так и без него.
Мы не будем рассматривать решение с автономным WireMock сервером, таким образом, нам не придется создавать его .jar-файл, делать необходимые настройки и активировать их до выполнения теста. Это решение приведено в другой статье — тут.
Мы рассмотрим последовательность шагов для организации работы с моками без запуска автономного сервера.
Шаг 1. Создание проекта и добавление зависимостей
Для начала создадим Maven-проект и назовем его “wiremock-example”:
Мы используем WireMock для создания моков и стабов, Rest-Assured в качестве HTTP-клиента и JUnit 5 в качестве тестового фреймворка. Ниже показана структура нашего проекта:
Как видите, внизу скриншота есть файл glossary.json. В этом файле у нас хранится тело стаба (см.ниже). Путь до файла resources -> __files -> json.
Кстати, можно проверить свой json на сайте http://jsonpath.com/. А мы проверим название файла в качестве значения поля. Его json-path ниже:
Шаг 2. Реализация первого теста и стаба
Во-вторых, мы создадим стаб и выполним тест в коде ниже:
Для начала переименуем WireMock-объект:
Затем запустим mock-сервер на выделенном порте и определить настройки для всех тестов:
Мы должны задать для нашего стаба следующие параметры:
- мы должны задать endpoint нашего url.
- мы можем определить content type.
- определить статус ответа.
- и связать при помощи метода .withBodyFile с телом запроса из файла “json/glossary.json”, который мы уже приготовили.
В конце каждого теста мы должны остановить мок-сервер:
Шаг 3. Настройка одного эндпоинта c различными условими
Мы добавляем другой пример стаба для двух условий:
- валидный запрос
- невалидный запрос
В настройках стаба, как показано выше, мы задаем эндпойнт /some/thing .
Первый стаб вернет ответ с 503 статусом и сообщением “Service Not Available”, если в Header.Content-Type =Accept:text/plain.
Второй стаб вернет ответ с валидным телом и 200 статусом, если Header.Content-Type =Accept:application/json.
Для более реалистичной симуляции мы добавили задержку в 2500 мс.
Оставшаяся часть кода — это тестовые методы Rest-Assured. Больше информации swtestacademy. Ссылка на проект: github.
Вывод
Надеюсь, у вас (как и у меня) по этой подробной инструкции получилось понять, как работают моки и что нужно для их добавления в проект.
С помощью WireMock вы сможете решить некоторые проблемы проекта. Например: конфигурировать систему под нужды автотестов, задать определенные тестовые условия, обеспечить атомарность проверок, ускорить прогон автотестов за счет исключения запуска тяжелых подсистем.
____________________________________________________________________________________
Рекомендуем подписаться на наши соцсети и блог — там мы регулярно публикуем интересные кейсы, новости, анонсы онлайн-мероприятий и вдохновляющие истории успеха:
Telegram: https://t.me/simbirsoft_dev ВКонтакте: https://vk.com/simbirsoft_team Яндекс Дзен: https://zen.yandex.ru/simbirsoft Habr: https://habr.com/ru/company/simbirsoft/blog/ YouTube: https://www.youtube.com/user/SimbirSoft/
