Что-то наболело.
Представим себе такую ситуацию - у вас есть под сотню UI тестов и в один прекрасный день находится бага, которая блочит последующее выполнение тестов. Костылять только лишь один этот тест ради того, чтобы он не блокировал последующие - такое себе решение.
Под блочить имею ввиду, нажимаете вы кнопку на форме - а она не закрывается вообще.
Отловить такие моменты в тестах - сложная задача, учитывая тот факт, что такое может произойти где угодно.
Как вы поступаете в этом случае ?
Просто дизейблите тест, а остальные оставляете включенными ?
Просто я к тому, что невозможно написать UI тесты таким образом, чтобы они были максимально атомарными и независимыми друг от друга. Всегда найдётся такой, который будет хоть как-то, но афектить другие.
Вообще же, рекомендуют: 1 тест - 1 ассерт, но такого в реальности почти нет.
В реальности картина, вроде:
a) pre-setup, где мы подготавливаем окружение к тесту
b) собственно, сам тест
c) очистка
И всё это делается через UI.
В связи с чем, вопрос:
Это ошибка в дизайне кейсов/сценариев ? Или что ? Или всё нормально и так и должно быть ?
Кто-нибудь сталкивался с таким ? И если да, то как решали ?
А зачем вы и сетап и очистку делаете через UI ?
Я понимаю что есть тесты где до момента ассерта вы проходите флоу и если там формв не открывается то хорошо пусть жти тесты будут упавшими - напрягайте разрабов чтобы чинили, а так то что к тесту не относится делайте не через UI
в идеале то, что можно тестировать без браузера, надо тестировать без него, а ui тесты писать именно для валидации каких-то критичных интерфейсных вещей
ибо если у вас есть доступ к исходникам, то никто не мешает написать кучу быстрых апи тестов условного бэкенда, заморочиться и заставить фронтедеров тестировать ui компоненты, а самому уже потом понять, где слабое место в получившейся ситуации и добить все сверху селенидом
другое дело, что в реале заказчики тестирования хотят полное покрытие продукта ui тестами, ибо это, то как работают пользователи и именно это и надо тестить; тут надо либо подстраиваться, либо убеждать в том, что поддержка только ui тестов это долго и дорого
другое дело, что в реале заказчики тестирования хотят полное покрытие продукта ui тестами, ибо это, то как работают пользователи и именно это и надо тестить; тут надо либо подстраиваться, либо убеждать в том, что поддержка только ui тестов это долго и дорого
Я бы вам рекомендовал переубеждать тех кто вам поставил такую задачу.
Ваша задача выполнить тестирование качественно и показать результат.
Выполнение сетапа на UI это не есть good. Выполнение очистки на UI вообще за гранью понимания.
Понятно что не всегда возможно выполнить сетап иначе, но смысла и очистку и сетап каждый раз через ui делать нет из за этого как раз и возникают проблемы чтотвы описали выше, когда ломается чтото не относящееся именно к тесту и ваш тест по сути заблокирован тем что вUI сетапе чето там сломалось.
Тесты должны быть атомарными значит что каждый тест может быть запущен отдельно и независимо от остальных, если у вас так не получается значит есть проблема.
ну вот вы и подстраиваетесь. заказчикам тогда это всё и показывайте под соусом - мол вот к чему приводит тестирование только через UI. ну и вообще - вы же знаете про пирамиду тестирования, да? ну ту самую, которую в школе проходят и где всем толдычат что UI тестов должно быт мало. очень мало. и что они должны быть атомарнными. верю что вы все знаете, а заказчики имеют право не знать. вот вы им покажите и расскажите.
ну и тезисно к тому, что уже сказано выше:
делать сетап\очистку через UI делать допустимо если по другому ну вообще нельзя. но это рики
тесты строго независимы. если один тест упал - он добавляется в игнор лист с пометкой баги. игнор кейсы регулярно ревьюятся на предмет починки
делать полное покрытие через UI долго дорого и глупо. у меня есть такой проект рядом ибо это легаси монолит, который никто не будет уже дробить на нормальный бэкенд-фронтенд. и да, там это долго дорого и глупо
testomat.io управление авто тестами
