Как происходит обработка ошибок от бэкенда на фронте, примеры отображения ошибок при потере связи
Что проверяют
Умеете ли вы тестировать не только «счастливый путь», но и поведение интерфейса, когда сервер отвечает ошибкой или не отвечает вовсе. Следом обычно просят показать, как вы воспроизведёте потерю связи или ответ 500 без помощи разработчиков.
Как отвечать
Сначала покажите, что различаете классы ошибок и для каждого знаете ожидаемое поведение:
- 400 и 422: ошибки валидации. Сообщение привязано к полю, введённые данные не пропадают;
- 401: сессия истекла, пользователь уходит на вход, а после входа возвращается туда, где был;
- 403 и 404: понятный текст «нет доступа» или «не найдено», а не пустая страница;
- 500, 502, 503: общее сообщение без стектрейса и технического JSON, с кнопкой «повторить»;
- таймаут и обрыв сети: ответа нет вовсе. Спиннер не должен крутиться бесконечно.
Полезно знать деталь реализации: fetch не выбрасывает исключение на 4xx и 5xx, только на сетевой сбой, поэтому разработчик сам проверяет response.ok. Отсюда частый баг: ошибка сервера выглядит как успех. А navigator.onLine говорит лишь о наличии сетевого подключения, не о доступности сервера.
Инструменты:
- DevTools: режим Offline и троттлинг во вкладке Network, блокировка отдельных запросов;
- прокси: Charles, Fiddler или mitmproxy подменяют статус ответа или задерживают его;
- автотесты: в Playwright
page.route()возвращает любой ответ, аcontext.setOffline(true)имитирует обрыв.
Проверяйте, что после восстановления связи данные подтягиваются, а повторная отправка формы не создаёт дубль.
Где спотыкаются
Проверяют только выключение Wi-Fi целиком. Самые неприятные баги живут в частичных сбоях: один запрос из пяти упал, ответ пришёл через 40 секунд.
Смотрят, что сообщение появилось, и не смотрят на данные: заполненная форма очистилась, заказ ушёл дважды после «повторить».
Принимают любой текст ошибки. Надпись «Error: 500» или сырой JSON в интерфейсе стоит заводить багом, пользователю из них непонятно, что делать.