От проверки шрифтов до HAR-файлов: оцениваем инструменты для ускорения работы тестировщиков

Штука может пригодиться, если у вас очень, очень много запросов. В этом случае, конечно, надо бы стучать фронту по голове - так быть не должно, но фильтры пригодятся.

Зачем стучать фронтенду по голове, если количество запросов зависит от схемы данных у бэкэнда? Правда если бэкэндер будет отдавать все за один запрос, то рано или поздно случится ситуация «Зачем вы отдаете мегабайт данных, которые формируете пару секунд, если нам нужно одно поле... Руки бы оторвать этому бэкэндеру» х)

Мы с помощью cypress кроме полного e2e тестирования

e2e тесты напрямую зависят от сложности вашей системы. Если вы можете поднять все на локальной машине (или в CI) по щелчку пальцев, штош, это определенно приятно. Но иногда организация тестового окружения может удвоить стоимость содержания и обслуживания системы и бизнес может не согласиться с такими условиями.

Так что я бы сказал так: главный инструмент тестировщика - автоматизированные тесты.

После работы тестировщиком больше 12 лет могу сказать, что главный инструмент тестировщика - это мозг.

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

И, кроме того, автотесты - это checks, а не tests.

Да, я согласен, что если что-то надо делать руками регулярно, это можно автоматизировать, чтобы освободить время для exploratory тестинга. И Cypress - это отличный инструмент в некоторых случаях (в том числе и за счет cy.intercept()), как и Playwright (который тоже умеет в перехват запросов). Единственное только, тестирование - это контекстно-зависимая штука, и контекст, в котором вы говорите, насколько я понял, - это только фронтенд. Не все могут в контекст.

Я не согласен, что автотесты это прям главный инструмент. Это скорее главный инструмент автоматизации регрессионных проверок в этом контексте, только и всего. А это достаточно малая часть тестирования. Плюс поддержка и актуализация этого всего. Опять же, на фронтенде свет клином не сошелся, там кроме него еще лютое количество вещей, которые надо тестировать.

Тестирование - это гораздо более широкая область, чем вы тут описали.

По поводу вашего коммента ниже - тоже согласен, можно автоматизировать проверки на фронте за пару пятничных вечеров, но, вы же понимаете, что это только самое начало? Мало написать, надо поддерживать, актуализировать, где возможно и имеет смысл - спускать на более низкий уровень пирамиды тестирования. Просто хотя бы потому, что я могу прогнать 300 API тестов за минуту и гораздо меньше E2E сценариев за то же время, даже если перехватывать запросы на бэк. И зря вы так категорично сразу про GraphQL. Хорошая штука, но... Если на бэк идет много запросов (почему, собственно, он их и отдает, он же не сам решает вам жысонов в браузер напихать), то надо думать об архитектуре в первую очередь, доменной области и как там представлены данные, и почему в этой модели фронтенд хочет эти разные данные. Может так случиться, что GraphQL не понадобится, потому что он только сделает хуже, хотя бы потому, что данные через REST можно получать в параллель, и так далее.

Проблема не написать скрипты. Проблема соблюдать баланс в течение длительного времени, чтобы не гонять потом E2E скрипты часами после каждого мёрджа. Кстати говоря, если вы гоняете E2E исключительно на фронте (без бэка), то это тоже не обязательно хорошо, ибо синтетическое окружение, после интеграции можно получить кое-каких сюрпризов, если у вас бэк не прям реактивный.

К статье еще бы добавил блокировку запросов по маске в Dev Tools.

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