testomat.io управление авто тестамиДля начала расскажу, как я столкнулся с контрактным тестированием. QIWI активно занимается электронной коммерцией. Основной продукт здесь – QIWI Кошелек, за которым стоит целая экосистема микросервисов, позволяющая проводить платежи.
Достаточно серьезным шагом для нас было открытие протокола (Open API) всему миру. С этого момента мы должны не просто контролировать обратную совместимость внутри своего контура, но и нести обязательство перед пользователями нашего Open API. Никто ведь не будет пользоваться API, которое ломается от версии к версии.
Расскажу историю. Я тут недавно присматривал квартиру и первый вопрос с которым я столкнулся, «какой конструкции дом выбрать». Сначала весь дом пронизывают арматура, потом с помощью вот этих желтых форм отливается сам монолит. Из него получаются крепкие и надежные жилища.
С другой стороны, существуют панельные дома. Есть заранее отлитые части - панели, которые надо каким-то образом состыковать друг с другом. К сожалению, реальность такова, что периодически в месте их стыков продувает, и чтобы комфортно жить, следует заделывай их пеной и ватой.
Эта история похожа на монолитный (даже называется также) и микросервисный подход к конструированию backend-систем. Единое целое и кусочки, которые надо как-то связать.
Если кратко о плюсах монолита, то его легче деплоить, откатывать, проще поддерживать транзакционность, код выполняется внутри одного артефакта. Из минусов: откат убирает весь функционал, а не только багованый. Большая связанность накладывает ограничения по структуре проекта и выборе языка.
Микросервисы же это обратная сторона монолита, поэтому почти все минусы монолита превращаются в плюсы для микросервисов и наоборот. Можно писать каждый сервис на любом языке и устроить другую чехарду с технологиями и подходами.
Хотя нет четкого определения, когда сервис становится микро, для этого backend-тестировщика одна из главных головных болей при работе с большим скоупом сервисов - это распределенность и инфраструктура.
Как хорошо было несколько лет назад.
Один раз научился поднимать приложение да хоть локально, накидал в него запросы и получить результат. Проблема практически наверняка будет в этом огромном монолите, захотел посмотрел логи или даже подебажил. Нашел, где проблема и показал разработчику или поправил, чего уж.
С приходом миросервисов встает много вопросов: Как поднять всю цепочку сервисов, если разработка одной фичи идет параллельно? Может их замокировать? Сколько на это уйдет ресурсов? Как быстро выяснить сервис, в котором проблема? Где лежат логи? Всем ли пропилена сеть? Корректно ли синтегрированы сервисы по API? Не будут ли нарушены контракты?
Еще раз, я не пишу, что микросервисы гораздо хуже монолита, они просто другие. Подходы с ними тоже должны быть другими. Сравните, как эта интеграционная звезда смерти микросеврисов выглядит во многих компаниях, и задумайтесь надо ли оно вам. Netflix это может, но не все могут делать как Netflix.
Исторически одной из первых проблем, с которой мы столкнулись при переходе на микросервисы, было полное отсутствие документации и понимания контрактов (что сервис обещает своим пользователям). Если вспомнить про стройку – то насколько одна панель подойдёт к другой без боли?
Создатели Swagger попытались это решить и сейчас это возможно самая известная программа для работы с API, программа поддерживает кучу языков и имеет большое комьюнити. Из этого интерфейса можно просмотреть все ендпоинты, проанализировать структуру запроса, какие поля обязательные, какие нет, посмотреть на пример запроса. Можно отправить запрос, естественно получить ответ. Также будет сформирован CURL. Короче, отличный комбайн для быстрой отладки API.
Помимо этого красивого UI в toolkit входит модуль swagger-codegen. С его помощью можно напрямую из кода разработки генерировать не только документацию, но и клиенты и заглушки.
Не работать swagger-подход может из-за главного двигателя прогресса - лени. Ну или отсутствия процесса поддержки актуальности документации. Я считаю, что плохая документация хуже, чем ее полное отсутствие. Лучше заранее не предоставлять никакую информацию, чем давать ложную надежду вашим клиентам о сервисе. Да, всегда можно уточнить информацию живьем. Но если сервисов сотни, тысячи? Пусть машины делают это и надеются на нас.
Если хотите узнать, как решить проблему сохранения обратной совместимости обещанных контрактов от одного сервиса другому? Приходите 24 мая на MeetUP «QAчественное общение» в Corporate Innovations Hub, расскажу вам еще больше интересных кейсов по тестированию с применением Pact, Schema Validation, Zipkin, Serialization Data и других решений.