Можно ли тестировать фронтенд без бэкенда при статусе fail в callback

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

Не останавливаетесь ли вы, когда бэкенд отвечает ошибкой, умеете ли локализовать дефект по слою и знаете ли, чем подменить ответ. За таким вопросом обычно стоит реальная ситуация из их проекта.

Как отвечать

Сначала локализация, потом выводы. Открываю сетевую вкладку и смотрю сам обмен: какой запрос ушёл, что вернулось, код ответа, тело, заголовки. Если запрос сформирован верно, а сервер вернул отказ, дефект бэкендовый, и в тикет идут запрос, ответ, время и идентификатор трассировки.

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

Чтобы не зависеть от сервера, ответ подменяется. Варианты: перехват на уровне сетевого слоя приложения через MSW, правила подмены в прокси (Charles, Proxyman, Fiddler), переопределение ответа в DevTools, локальный стаб или мок-сервер вроде WireMock. Полезно дополнить сверкой ответа со схемой, иначе мок со временем разойдётся с настоящим API.

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

Заводят баг с формулировкой про то, что ничего не работает, без запроса и ответа. Такой тикет возвращается на уточнение, а между возвратами проходит день.

Проверяют только на моках и закрывают задачу. Мок отвечает мгновенно и всегда одинаково, поэтому гонки, долгие ответы, повторные клики и пустые состояния на нём не воспроизводятся.

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