Тема дня связка бэка с фронтом.

Не секрет, что главные проблемы в ИТ не технические, а связанные с miss communication.
Типичная проблема - разногласия между командами бэкенда и фронтенда.

Рассмотрим ситуацию: бэкенд выставляет АПИ, фронтендщики им активно пользуются. И как обычно что-то в процессе разработки отваливается, ломается. Бэкендщики что-то задеплоили на дев в 2 ночи, с утра пришли фронтэндщики - и ничерта не работает.

Обычно команды митигируют этот риск следующем образом:
1) Команда фронтенда мокает бэкенд. С одной стороны это самый надёжный вариант: "Бэк" доступен с локальной машины или со специально отведённой на это машины. Но я этот вариант люблю меньше всего: его очень дорого поддерживать. Так как АПИ меняется, то много времени приходится тратить именно на доработку мока АПИшки. Также момент отлавливания ошибок на бэкенде откладывается до выката релиза на стэйджинг, ведь до этого момента фронтенд не взаимодействует с бэком, а по сути, именно фронтендщики являются тестировщиками бэка.

2) Разворачивать бэкенд локально на машинах фронтэндщиков. Более приемлемый на мой взгляд вариант, когда фронтендщик может локально развернуть бэкенд на своей машине. Сложности начинаются, когда бэкенд не представляет из себя монолит или требует очень много ресурсов. Это затрудняет работу разработчиков, но зато позволяет отлавливать ошибки бэкендщиков раньше. Ведь по умолчанию у разработчика будет развёрнут актуальный дев, и только в случае, если он некорректно работает, фронтендщик будет запускать устаревшую, но исправную версию.

3) Содержание стабильного стэйджинга для бэка, с которым по умолчанию работает фронт. Вариант очень хорош: фронтендщики по умолчанию работают с девом, но, если тот падает, переключаются на стэйджинг. С каким бэком работать - разработчики выбирают через переменные среды или заранее установленные константы. Минус - стоимость поддержки стэйджинга. Может быть высокой и нецелесообразной на начальных стадиях проекта.

Глупо было бы не использовать АПИ тестирование для избегания этих проблем. Причем стоимость этого решения значительно дешевле, чем вышеприведённые варианты.
Допустим, АПИ содержит 100 методов, из них фронтендщики активно используют 20-30. Достаточно написать 20-30 тестов с двумя assertions и прогонять их в рамках ci/cd процесса на бэке или хотя бы просто запускать их раз в 10 минут, чтобы знать состояние АПИ. Assertion'а достаточно два: на статус запроса и на проверку его контента. Обычно нам достаточно знать, что запрос возвращает 200 и ответ содержит какой-то id или какую-то стрингу. Дёшево и сердито, зато надёжно и является стартовой площадкой для последующего полноценного интеграционного и нагрузочного тестирования.

Конечно, можно было бы также сказать, что «Надо просто настроить нормальный мониторинг с нотификациями и алертами», и с этим сложно не согласиться. Но есть ситуации, когда подобные АПИ тесты будут более эффективны и востребованы.