Каково соотношение тестирования фронтенда и бэкенда
Что проверяют
Понимаете ли вы, что проверять надо на самом низком уровне, где проблема обнаружима.
Как отвечать
Универсального соотношения нет, но есть принцип: проверка ставится на том уровне, где дефект можно обнаружить дешевле всего.
Отсюда распределение по смыслу:
На бэкенде через API проверяется всё, что связано с данными и правилами: расчёты, валидация, права доступа, статусы и переходы между ними, обработка ошибок, идемпотентность, пагинация, работа с граничными значениями. Это быстро, стабильно и не зависит от вёрстки.
На фронтенде проверяется то, что существует только там: отображение состояний (загрузка, ошибка, пустой список), поведение форм, навигация, адаптивность, доступность, работа при медленной сети и при ошибке сервера, сохранение состояния при обновлении страницы.
Главная ошибка, которую и хотят услышать: проверять бизнес-правила через интерфейс. Пятнадцать сценариев расчёта скидки, прокликанных в браузере, работают в десятки раз медленнее тех же проверок по API и ломаются от любой правки вёрстки. Через интерфейс достаточно убедиться, что результат корректно отображается, а варианты расчёта закрыть на уровне API.
Отдельная зона это стык: соответствие ответа контракту. Тут помогают проверка схемы и контрактные тесты, которые ловят расхождение раньше, чем оно доедет до экрана.
По времени распределение сильно зависит от продукта: в системе со сложной логикой и простым интерфейсом основная работа на бэкенде, а в интерфейсно насыщенном продукте наоборот.
Полезный приём при проверке фронтенда: подменять ответы сервера через прокси, чтобы воспроизвести ошибки и редкие состояния, не прося бэкенд их создавать.
Где спотыкаются
Проверяют логику через интерфейс.
Не умеют подменить ответ сервера и не тестируют состояния ошибок.
Не проверяют соответствие ответа схеме.
Делят работу по привычке, а не по тому, где дефект дешевле поймать.