Comments 14
Да, selenium классная штука, тоже использую его. Единственное, что он не решает все проблемы, например не покажет что css съехал, или какой то блок исчез (если не проверять каждый блок на странице). То есть для тестирования фронтэнда приходится что-то другое использовать. Как то пробовал https://github.com/garris/BackstopJS чтобы сверять скриншоты страниц перед и после обновления.
То, что css съехал и дизайн кривой, это он не проверит. Зато можно проверять варианты типа CTA (главная кнопка ради которой создавался сайт) всегда на первом экране на любых разрешениях браузера.
Вот такие проблемы бывают - на десктопе видно кнопку "купить товар" сразу, а на мобильнике она уехала на второй экран или схлопнулась в меню, конверсия упала, маркетологи в ужасе. На такое можно написать e2e тест, а заодно проверить что все всплывающие "мы используем куки", "Летняя акция -20% на всё" и "я ваш персональный чат-бот ассистент, чем вам помочь" не закрыли собой всё остальное.
Силениум или playwright умеют делать скрины страницы. Остается подсунуть этот скрин ИИ и образец и получить ответ сходятся или нет
Писать e2e тесты не сложно если есть хоть какие-то базовые понятия программирования. У того же селениума есть авто запись всех действий пользователя. Остается только немного подкорректировать. По настройке автотестов можно попробовать playwright он ставится одной командой без всяких танцев с бубном как в селениуме.
Использовал Dusk для одного проекта - решил всё покрыть тестами. Проблема была со фронтендом, который генерится при помощи LiveWire - там чистые танцы с бубнами.
Для Dusk всё равно чем генерится html страницы, пока Flash с java-апплетами в проекте не появляется, он может тянуть тесты.
Я как раз и писал, что надо научиться с ним работать так, чтобы плясать не приходилось, на это уходит время.
Всё это так, когда я сам писал свой фроненд или я знаю, что в нём происходит - тогда всё пишется хорошо. Но вот Вы пробовали писать эти тесты для сайта, созданного при помощи filamenta?
Это не значит, что я против e2e тестов, совсем наоборот.
Для филамента - нет. Для срм на голом php, которая была написана без моего участия - да. Там было много таблиц, в которых от 16 до 32 столбцов, по клику на столбец в модалке другая таблица и так далее. А внутри каждой ячейки свой набор элементов.
В филаменте можно как минимум css-класс элементу выдать в принудительном порядке. А дальше вот такое придётся делать
$elements = $browser->elements('.my-class');
foreach ($elements as $element) {
$element->click();
}Dusk должен уметь нормально поддерживать иерархию элементов по принципу css '.card .btn'
они очень хрупкие, в моей жизни на одном проекте с этими тестами была одна морока, они могут упасть не только из-за изменения кода или бага, а из-за разных причин, эти тесты комплексные, в их прогоне участвует сеть, база, весь стек проекта, а из-за сложности они еще и медленные, у нас прогонка всех селениум тестов проходила 8 часов, и если какой-то тест упал, то не факт, что есть проблема, так как во многих случаях может просто быть затуп или сеть отстегнулась, е2е тесты - это дорогое удовольствие, и нужно оно не только лишь всем, мало кому нужно
Для таких целей есть Selenium Hive чтобы гонять тесты параллельно, а не последовательно. Там ещё можно и под разными ОС смотреть. Под Hive есть платные облачные сервисы.
Покрывать e2e тестами надо лишь критичные для бизнеса процессы, а не всё подряд, второстепенный функционал без которого проект может худо-бедно жить, в Selenium можно не добавлять.
Отстегнулась сеть и т.д. - вот это не "проблема плохого теста", а "выявленная тестами проблема сети инфраструктуры". Мне же не надо рассказывать, что в пиковую нагрузку под реальными пользователями плохо работающая сеть тоже может отвалиться? Если какие-то тесты падают в кубернетах Яндекса, это не проблема тестов, это кривость работы кубернетов Яндекса на которые лишь ленивый не грешил.
Длительность тестов упирается в железо. Когда я запускал тесты на ноуте с 16Гб оперативы где уже был запущен phpstorm, Postman и все контейнеры проекта, мои тесты тормозили ужасно. А вот когда я перешел на ПК с 64Гб оперативы, те же тесты летали. Тут надо определяться, либо мы хотим "дорого-богато" и тратимся на рабочие часы программистов и железо в том числе для тестов, либо мы экономим и открываем багрепортницу для наших клиентов.
e2e нужны не более и не менее чем все остальные тесты на проекте. У меня как-то был забавный случай, я поменял URL с локального на тестовый сервер. После теста на логин сеть отвалилась, даже по ssh. Оказалось, сисадмин когда-то написал скрипт, если происходит 3 попытки логина с запредельной для человека скоростью, сервер по f2b банит этот IP на 10 минут, проверить эффективность скрипта у него не было возможности, в гите скрипта нет, так что разрабы про существование скрипта не знали. И вот сидим всем отделом, тестовый сервак нас забанил, а сисадмин весёлый по офису прыгает.
Почему e2e тесты это круто, но никто их не пишет. На примере Laravel Dusk