Бывало ли у вас так, вы начинаете регресс и выясняется, что одна из систем вдруг не работает? И это блокирует всю систему и блочит регресс? Оказывается одна из систем исправила один небольшой баг и это поломало контракт. И к примеру, встала очередь в кафка.
Такое может случиться и на релизе.
В моей практике такое бывало.
⚠️ Это нас приводит к важности контрактного тестирования, как одного из гейтов релизного пайплайна.
👇👇👇👇👇👇
Контрактное тестирование - это когда команда ведет разработку так, чтобы такие изменения ловились до релиза, автоматически в ci/cd.
А Pact - один из самых популярных способов это организовать.
Суть простая:
1️⃣ Потребитель фиксирует ожидания
Потребитель (consumer) - тот, кто вызывает API. Для простоты в моей истории это будет фронт.
Он говорит: "когда я делаю вот этот запрос, я ожидаю вот такой ответ: такие поля, такие типы данных, такая структура".
Фронтендер разрабатывая фичу пишет небольшой контрактный тест. Разработав функционал он запускает тест используя mock бэка. Если тест проходит успешно мы получаем артефакт: pact-файл в JSON формате. Это и есть наш контракт. Файл кладется в хранилище контрактов (может быть просто каталог в репозитории)
2️⃣ Бэк проверяет, что не сломал ожидания
Дальше провайдер (provider) - в моей истории это будет бэк - в пайплайн своего деплоя добавляет этап верификации контрактов. На этом шаге CI берётся этот pact-файл, поднимаются эндпоинты новой сборки и проверяется контракт.
Если не совпадает - сборка не проходит дальше. Анализируем -> исправляем -> пробуем снова собрать релиз.
Это дает нам достаточно надёжный Gate ⛩не пропустить в релиз критичный баг.
🤔 Где тут QA? Спросите вы.
Сам контрактный тест пишут как правило dev’ы.
Но QA очень помогает, когда:
👉 выбирает что именно контрактовать (мы не проверяем всё подряд!)
👉 задаёт строгость (какие проверки must-have, что критично?)
👉 следит, чтобы контракт не был "ни о чём" или наоборот - не был избыточным
Если вы прочитав этот пост поняли, что у вас нету такого, не стоит сразу бежать к команде и кричать, что нужно внедрять PACT.
Но если у вас на проекте периодически встречаются ситуации, как та что описана вначале поста, то это прям повод задуматься.
Если фронт и бэк релизятся отдельно и API часто меняется - Pact обычно окупается.
При интеграциях почти всегда must-have.
Но если у вас пока проект не большой, всё выкатывается вместе и почти не меняется - можно не усложнять. 🫡
Напишите в комментариях у вас есть контрактное тестирование? Используете pact или другой подход?
🌐 Сайт | 💼 LinkedIn | 📘 Курс по Postman
