Как подсвечивать ошибки бэкенда в приложении

Что проверяют

Умеете ли вы отличить баг фронта от бага бэкенда и доказать это в баг-репорте, а не написать «кнопка не работает». Вторая часть: проверяете ли вы, как приложение показывает серверные ошибки пользователю. Следом часто дают случай: экран пустой, ошибок в интерфейсе нет.

Как отвечать

Сначала о том, как увидеть то, что интерфейс скрывает:

• трафик: вкладка Network в DevTools для веба, Charles, Proxyman или mitmproxy для мобильных. Смотрите код ответа, тело ошибки, время, заголовки;
• корреляция: request id или trace id из ответа ищется в логах бэкенда (Kibana, Grafana Loki) и в Sentry. С ним разработчик находит стек за минуту;
• провокация ошибок: подмена ответа через Map Local или Rewrite в Charles, моки в WireMock, отключение сети, таймауты. Так проверяются 401, 403, 404, 409, 422, 429, 500, 503 без поломки стенда.

Затем что проверять в самом приложении:

• сообщение: пользователь видит понятный текст и действие («повторить», «войти заново»), а не сырой JSON или стек;
• валидация: ошибки 400 и 422 с указанием поля подсвечивают конкретное поле формы;
• состояния: индикатор загрузки не висит вечно, введённые данные не теряются, повтор не создаёт дубль заказа;
• контракт: формат ошибки единый, например Problem Details по RFC 9457, и клиент разбирает его одинаково.

В баг-репорт кладите запрос, ответ, код, request id и время: это сразу снимает спор «фронт или бэк».

Где спотыкаются

Проверяют только интерфейс. Если фронт глотает ошибку и показывает пустой список, баг выглядит как «нет данных» и уходит не той команде.

Считают, что код 200 означает успех. Бывают API, которые кладут ошибку в тело при статусе 200, и это отдельный дефект контракта.

Тестируют только счастливый путь, потому что «сломать бэкенд на стенде нельзя». Подмена ответа через прокси занимает пару минут.