Comments 5
Проверка шрифтов
Будет полезно в случаях, когда кажется, что шрифт одного из элементов на странице отличается, или когда на странице используется большое количество различных шрифтов и элементов.
Если шрифт отличается, Devtools -> inspect element и стили смотреть. Чем может список шрифтов - не ясно. Второй довод про много шрифтов и элементов - вообще непонятно о чем, если их много, то много их будет в Devtools, чем это поможет - мне решительно не ясно.
Режим редактирования всего документа
Эта фича будет полезна, если при проверке UX-макета необходимо понять, что произойдет, если у одного или нескольких элементов изменится длина названия или объем содержимого.
Это называется Unit тестирование, весьма печально, если кому-то реально нужно вводить текст руками чтобы посмотреть что будет.
Неклассические скриншоты
Полезная штука, согласен. Нюанса два - если у вас программный lazy load, то на скриншоте ничего не будет ниже окна, а если lazy load нет, а страница длинная - получится длинная картинка, которую очень проблемно кому-то отправить - она будет пережата на 10 джипегов из 10.
Скриншоты узлов
Неплохая штука, но по факту не нужна. win+shift+s сделают эту работу на порядок быстрее.
HAR-архивы
Вероятно, самая полезная вещь в списке. Когда запросов много, и что-то неявно в них сломалось без ошибок, и при этом нет чего-то вроде kibana или ее аналогов - понять что произошло будет очень сложно.
Редактирование запросов
Бывают ситуации, когда необходимо проверить данные, которых нет на бэкенде, или отправить на бэк значения, которые невозможно ввести на фронте.
Проверить данные, которых нет на бэке эта функция никак не поможет, потому что она умеет только отправлять измененные значения. Если вам часто нужна такая фича - вам нужен posman или что-то вроде того, хотя в идеале для этого нужно e2e писать. По факту - если нужно что-то по-быстрому проверить, не поднимая, и не настраивая приложение для тестирования API - пойдет.
Фильтры (для network)
Штука может пригодиться, если у вас очень, очень много запросов. В этом случае, конечно, надо бы стучать фронту по голове - так быть не должно, но фильтры пригодятся. По факту же из всех фильтров достаточно ткнуть на "Fetch/XHR". Дальше все глазами находится на порядок быстрее написания фильтра в этом маленьком и неудобном окошке.
А теперь самое главное - если вы это каждый раз делаете руками, то это очень плохие новости. Все это должно быть полностью покрыто тестами, которые могут все перечисленное прогнать и проверить результат. И если Unit-тестирование за 2 часа на коленке не напишешь, то поднять cypress/playwright можно буквально за день, автоматизировав всю рутину по подобному тестированию. Да что там вручную писать - тесты на cypress на удивление отлично пишет chatgpt, чем я, кстати, активно пользуюсь.
Там же можно и подменять запросы с бека, и эмулировать ввод, смотреть шрифты. Мы с помощью cypress кроме полного e2e тестирования, взаимодействия компонентов и прочего стандартного, измеряем количество потребляемой памяти, быстродействие, реакцию на скролл и еще кучу всего, что очень, очень сильно облегчает жизнь тестировщикам.
Еще в статье совершенно не затрагивается recorder и insights - которые помогают создавать и поддерживать быстрое, качественное приложение, а главное - записывать шаги для их воспроизведения разработчиком.
Так что я бы сказал так: главный инструмент тестировщика - автоматизированные тесты.
Штука может пригодиться, если у вас очень, очень много запросов. В этом случае, конечно, надо бы стучать фронту по голове - так быть не должно, но фильтры пригодятся.
Зачем стучать фронтенду по голове, если количество запросов зависит от схемы данных у бэкэнда? Правда если бэкэндер будет отдавать все за один запрос, то рано или поздно случится ситуация «Зачем вы отдаете мегабайт данных, которые формируете пару секунд, если нам нужно одно поле... Руки бы оторвать этому бэкэндеру» х)
Мы с помощью cypress кроме полного e2e тестирования
e2e тесты напрямую зависят от сложности вашей системы. Если вы можете поднять все на локальной машине (или в CI) по щелчку пальцев, штош, это определенно приятно. Но иногда организация тестового окружения может удвоить стоимость содержания и обслуживания системы и бизнес может не согласиться с такими условиями.
Если бек отдает кучу запросов - нужно использовать graphql или что-то вроде него. Я имел ввиду ситуацию, когда фронт запрашивает одинаковые эндпоинты постоянно.
Если у вас web-приложение, то автоматизировать e2e именно в формате прогона типовых сценариев - реально 15-20 строк кода на каждый тест. Разумеется, без валидации схем, запросов и т.д. (это правда поднимать может быть долго и проблематично), я про описанные случаи в статье - почти все перечисленное автоматизируется через cypress за пару пятничных вечеров.
Так что я бы сказал так: главный инструмент тестировщика - автоматизированные тесты.
После работы тестировщиком больше 12 лет могу сказать, что главный инструмент тестировщика - это мозг.
Да, я умею писать правильные автотесты. Нет, не все пишут их правильно. Нет, разработчики не покрывают тестами всё, что надо. Нет, для того, чтобы быть хорошим тестировщиком, не обязательно уметь кодить. Да, можно уметь кодить и при этом писать отвратные автотесты.
И, кроме того, автотесты - это checks, а не tests.
Да, я согласен, что если что-то надо делать руками регулярно, это можно автоматизировать, чтобы освободить время для exploratory тестинга. И Cypress - это отличный инструмент в некоторых случаях (в том числе и за счет cy.intercept()), как и Playwright (который тоже умеет в перехват запросов). Единственное только, тестирование - это контекстно-зависимая штука, и контекст, в котором вы говорите, насколько я понял, - это только фронтенд. Не все могут в контекст.
Я не согласен, что автотесты это прям главный инструмент. Это скорее главный инструмент автоматизации регрессионных проверок в этом контексте, только и всего. А это достаточно малая часть тестирования. Плюс поддержка и актуализация этого всего. Опять же, на фронтенде свет клином не сошелся, там кроме него еще лютое количество вещей, которые надо тестировать.
Тестирование - это гораздо более широкая область, чем вы тут описали.
По поводу вашего коммента ниже - тоже согласен, можно автоматизировать проверки на фронте за пару пятничных вечеров, но, вы же понимаете, что это только самое начало? Мало написать, надо поддерживать, актуализировать, где возможно и имеет смысл - спускать на более низкий уровень пирамиды тестирования. Просто хотя бы потому, что я могу прогнать 300 API тестов за минуту и гораздо меньше E2E сценариев за то же время, даже если перехватывать запросы на бэк. И зря вы так категорично сразу про GraphQL. Хорошая штука, но... Если на бэк идет много запросов (почему, собственно, он их и отдает, он же не сам решает вам жысонов в браузер напихать), то надо думать об архитектуре в первую очередь, доменной области и как там представлены данные, и почему в этой модели фронтенд хочет эти разные данные. Может так случиться, что GraphQL не понадобится, потому что он только сделает хуже, хотя бы потому, что данные через REST можно получать в параллель, и так далее.
Проблема не написать скрипты. Проблема соблюдать баланс в течение длительного времени, чтобы не гонять потом E2E скрипты часами после каждого мёрджа. Кстати говоря, если вы гоняете E2E исключительно на фронте (без бэка), то это тоже не обязательно хорошо, ибо синтетическое окружение, после интеграции можно получить кое-каких сюрпризов, если у вас бэк не прям реактивный.
К статье еще бы добавил блокировку запросов по маске в Dev Tools.
Извините, что так много. В заключение могу сказать, что, если вас устраивает то, что у вас есть, и облегчает жизнь людям, то и хорошо. Надо просто понимать, что тестирование это много больше, чем автотесты.
Средств сейчас новых повыходило - мама не горюй, не успеваешь уследить, что приглянулось недавно:
https://docs.replay.io/why-replay - позволяет полностью записывать историю стейтов браузера
https://polypane.app/product-tour/?ref=developers - браузер с моментальным просмотром на нескольких размерах viewport'a
browserstack/lambatest и т.д. клаудные решения гоняющие тесты одновременно на любом количестве браузеров, устройств и т.п. (скорее всего нам не доступны сейчас)
От проверки шрифтов до HAR-файлов: оцениваем инструменты для ускорения работы тестировщиков