Бывало ли у вас так, вы начинаете регресс и выясняется, что одна из систем вдруг не работает? И это блокирует всю систему и блочит регресс? Оказывается одна из систем исправила один небольшой баг и это поломало контракт. И к примеру, встала очередь в кафка. 

Такое может случиться и на релизе.

В моей практике такое бывало. 

⚠️ Это нас приводит к важности контрактного тестирования, как одного из гейтов релизного пайплайна.

👇👇👇👇👇👇
Контрактное тестирование - это когда команда ведет разработку так, чтобы такие изменения ловились до релиза, автоматически в 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