Привет, Хабр! Меня зовут Ира, я SRE в команде Samokat.tech. В этом посте хочу поделиться подходом в тестировании, которым мы пользуемся сами. Если вам при подготовке тестов часто приходится писать похожие друг на друга как две капли воды заглушки (или, как их ещё называют, «моки»), а затем заботиться о том, чтобы их развернуть, то вам может понравиться наше решение. Освободившись от части рутинных забот, вы можете уделить больше времени чему-то более важному.
Разношёрстные и хаотично развёрнутые в окружении заглушки – дорогие и неэффективные. В каждой отдельной заглушке разбирается в лучшем случае только одна команда, чаще только один человек. Со временем при накоплении критической массы они становятся фактически неподдерживаемыми.
Такие заглушки редко переиспользуются и что важнее, никто ими не делится, так как они либо тривиальны, либо написаны не самым лучшим способом (могут оказаться слишком сложными или неоптимальными).
Сложно представить тестировщика в роли доброго самаритянина, раздающего коллегам свои заглушки. Его к этому вряд ли что-то мотивирует, да и работы у него всегда прилично. Некогда отвлекаться! Так, давайте разгрузим немного нашего трудягу.
Общий подход к заглушкам
Системы, как правило, не живут сами по себе, зачастую они имеют множество интеграций, не все из которых будут включены в ваш объект тестирования. Иногда такая связь может указывать на внешний ресурс, который недоступен в вашем окружении. Тогда вооружившись любимым языком программирования, тестировщик приступает к написанию простой заглушки, для которой понадобится всего лишь пример запроса и ответа. В случае когда нам понадобится особая логика от заглушки, такая как задержки отклика или что-то поэкзотичнее (например, динамическое конфигурирование), то её придётся дорабатывать и пересобирать.
Для начала подумаем что хотим от нашего будущего решения:
Прежде всего хочется тратить минимум усилий на написание заглушки. Желательно, чтобы, имея документацию, её мог написать даже человек без особых скилов в разработке.
Важна и возможность переиспользования. Использовать чужие заглушки или их части существенно облегчит этап написания своих.
Хотелось бы иметь единый подход для всех таких заглушек, что позволит не только шарить их, но и компетенцию по ним.
Заодно нужно остаться в привычном стеке. Нам изначально была ближе Java, так как заметная часть бэкенда в Samokat.tech пишется на Kotlin. Деплой сервисов у нас осуществляется в Kubernetes с использованием helm-чартов, тому же принципу будем следовать и с заглушками.
Для начала неплохо, можно приступить к поиску решения.
Шаг 1: Выберем готовое решение (не потому что мы ленивые, хотя ладно, потому)
Зачем писать то, что уже написано за тебя? Вокруг много open-source решений, которые просто настраиваются. У них есть поддержка разных платформ и режимов.
Наши первоначальные минимальные требования к готовому решению были следующими:
имеется широкий функционал и/или потенциал к расширению;
обладает достаточной производительностью, чтобы покрыть текущие потребности;
не сложно в использовании.
На первых порах выбирали между hoverfly, wiremock и mockserver. Hoverfly хоть и казался внешне простым, но не подошёл по функциональности. Wiremock уже был ближе к истине за счёт поддержки Java, но бенчмарк показал, что он не всегда хорошо работает с большими телами ответа. При построении значительного по размеру параметризированного тела для ответа заглушка сразу после запуска выдавала на первый запрос чрезмерно большое время отклика - до нескольких минут.
В итоге пришли к mockserver. У него оказалась довольно неплохая документация, также он поддерживает несколько вариантов конфигурации: вызов API, с помощью конфиг-файла или же можно описывать формат работы на Java или JavaScript. Поведение mockserver определяется набором конфигураций, в которых описываются ожидаемые на вход запросы и формат ответа на них. Каждая такая конфигурация называется ожиданием или expectation. Они имеют широкий спектр параметров, а также поддерживают регулярные выражения.
Пример ожидания в mockserver:
new MockServerClient("localhost", 1080)
.when(
request()
// соответствует любым запросам, path которых начинается c "/some"
.withPath("/some.*")
)
.respond(
response()
.withBody("some_response_body")
);
На самом деле мы используем только часть функциональности среди множества режимов и возможностей. По началу производительность была неплоха, но далека от идеала. Однако, после отключения подробного логирования поднялась на приемлемый уровень.
Шаг 2: Делаем обёртку для удобства шаринга
Когда мы нашли удобное решение, многие команды уже имели какие-то заглушки. Часть из них была в виде отдельных сервисов, другие же были написаны с использованием фреймворков, но они оставались несистемными и сложными в поддержке.
Нам нужно было предоставить удобный способ работы с mockserver, чтобы расширить его использование. Большим плюсом стал тот факт, что подавляющее число наших тестировщиков могут хорошо работать с кодом.
Тогда мы подготовили решение-обёртку, использующее библиотеку mockserver. Поскольку нам было важно переиспользовать заглушки, мы разместили всё в одном репозитории.
В отдельном классе для каждой команды определяется набор ожиданий (конфигураций). При запуске заглушка инициализирует только ожидания, определённые в классе запускающей команды. Часто мы применяем ожидания, использующие дополнительный callback класс для более гибкого формирования ответа.
Пример ожидания с использованием callback класса:
public class CallbackActionExamples {
public void respondClassCallback() {
new ClientAndServer(1080)
.when(
request()
// соответствует любым запросам, path которых начинается c "/some"
.withPath("/some.*")
)
// заглушка будет отдавать результат выполнения TestExpectationResponseCallback.class
.respond(
HttpClassCallback.callback()
.withCallbackClass(TestExpectationRespondCallback.class)
);
}
public static class TestExpectationResponseCallback implements ExpectationResponseCallback {
// переопределим формирование ответа
@Override
public HttpResponse handle(HttpRequest httpRequest) {
String randomNumber = String.valueOf(new Random().nextInt(1000000));
// вернём простой параметризированный ответ
return response().withBody(String.format("Random body # %s", randomNumber));
}
}
}Прелесть в том, что вы можете повторно использовать методы, общие для разных команд. Например, единожды описав метод ожидания для авторизации, его можно использовать в классах разных команд.
Осталось описать общий чарт для развёртывания в кубе и мы получаем способ быстро поднимать описанные заглушки на любом стенде.
Шаг 3: Добавляем нужные фичи
Ещё несколько реверансов в сторону встроенной функциональности mockserver. Для некоторых задач оказалась особенно полезной возможность добавить ожидание на лету. Неважно какая конфигурация задана у заглушки, с помощью обращения к API возможно изменить её поведение без рестарта. Чаще всего такие ожидания имеют довольно простую логику, однако, и тут можно сделать что-то невероятное с помощью JavaScript.
Пример ожидания через API:
curl -v -X PUT "http://localhost:1080/mockserver/expectation" -d '{
"httpRequest" : {
"method" : "P.*{2,3}"
},
"httpResponse" : {
"body" : "some_response_body"
}
}'Для отладки каждая заглушка имеет встроенный дашборд по пути /mockserver/dashboard.
Мы также добавили в нашу обёртку сбор основных метрик заглушки с помощью micrometer. У решения высокий потенциал к расширению, например, мы также добавили поддержку почтового протокола smtp и работаем над полноценной поддержкой graphql.
Для запросов graphql может оказаться недостаточной базовая функциональность определения ожиданий, ведь все запросы имеют одинаковый uri и метод (например, POST /graphql). Усложняет ситуацию то, что тело запроса будет динамически меняться в зависимости от схемы и глубины запроса. Однако в первом приближении удалось побороть и такие сложности, написав универсальный класс на основе библиотеки graphql, который парсит тело запроса и динамически формирует ответ.
Попробуйте это сами
Мы реализовали всё, к чему изначально стремились: заглушки написать просто, они сами и подходы к их разработке активно переиспользуются ребятами из соседних команд.
Итоговое решение оказалось довольно лёгким в поддержке. Имея единый репозиторий, удобно отслеживать изменения по любым заглушкам. Полное отсутствие конфликтов в коде достигается верхнеуровневым ревью.
По ссылке можете найти репозиторий с исходниками решения для реализации нашего похода.
Мы продолжаем совершенствовать наш заглушечный контур. Сейчас мы имеем удобный инструмент, помогающий ускорить тестирование каждый день. Возможно у вас есть примеры задач, с которыми наш mockserver на стероидах не справится сходу – рассказывайте о таких в комментах!
