Как тестировать задачу, если бекенд еще не готов, а фронтенд уже разработан?

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

Умеете ли вы начать работу до готовности всей системы, а не ждать сложа руки. Интервьюер хочет услышать про контракт и заглушки, а следом спросит, как не пропустить расхождение моков с настоящим бэкендом.

Как отвечать

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

Дальше заглушки, по выбору команды:

• в браузере: Mock Service Worker (MSW), который часто уже есть у фронтенда, или перехват запросов в автотестах через page.route в Playwright и cy.intercept в Cypress;
• отдельный мок-сервер: WireMock, Prism, который поднимает мок прямо из OpenAPI, Postman Mock Server;
• прокси: Map Local и Rewrite в Charles или Proxyman, чтобы подменить ответ в уже собранной сборке.

Что проверять на моках:

• состояния экрана: загрузка, пустой список, ошибки 4xx и 5xx, таймаут, медленный ответ, очень длинные строки, большой список и пагинация;
• клиентская логика: валидация форм, форматирование дат и сумм, показ серверных ошибок в том формате, который задан контрактом;
• вёрстка и доступность: они от бэкенда не зависят вовсе.

Параллельно готовите тест-кейсы и данные для интеграционного этапа. Когда бэкенд появится, прогоняете сценарии на настоящем API, а моки остаются в регрессии для редких состояний вроде 503. Чтобы заглушки не разошлись с реальностью, помогают контрактные тесты (Pact) или проверка ответов по той же схеме OpenAPI.

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

Мокают только успешный ответ. Ценность заглушек как раз в ошибках и пограничных состояниях, которые на живом стенде воспроизвести трудно.

Пишут моки по догадке, без согласованного контракта. Когда приходит настоящий API, поля называются иначе, и половину тестов приходится переделывать.

Закрывают задачу как протестированную до интеграции. Честный статус: проверено на заглушках, интеграция впереди, и это видно в отчёте.