Вопрос назрел, друзья.
У нас в компании UI тесты (селениум, ест-но) хранятся в основном проекте (git), идея была - чтобы тесты писались с привязкой к релизу.
Не буду писать - какие у меня в связи с этим проблемы, какие плюсы и минусы. Основная проблема: тесты всегда запаздывают к релизу, поэтому часто тесты падают, а подправить их быстро нельзя, надо ждать следующего релиза.
Хочу у вас спросить - а как вы храните свои UI тесты? И почему?
То где хранятся тесты, никак особо не повлияет на скорость их написания
А от чего тесты падают?
И почему их нельзя править на текущем релизе?
У нас для каждого проекта тестирования свой отдельный репозиторий.
Вы, видимо, не поняли суть.
Вышел новый релиз, логика или локаторы сменились.
Вполне возможно проблема не в том, где лежат тесты, а в том, что энвайроментов с текущей и новой версией очень мало.
Как следствие пока пишутся тесты на одну версию, разработчики накатывают на тот же энв другую версию (тесты ломаются) - и такая гонка продолжается бесконечно.
Просто выделите для автоматизации один энв и стабилизируйте там необходимое количество тестов для определенной версии приложения. После этого можно сделать тег в своем бранче, указывающий что эти тесты работают стабильно на версии 1.0.0.
Затем можно приниматься за апдейт или расширение тестов для новой версии приложения.
Храним в одном репо с проектом.
У нас правило мы не мержим бранчи в дефолт ветку и не релизим фичу пока тесты не прошли.
Т.е. правка тестов включена в предрелизные работы.
Если дев задача привела к тому что тесты перестали работать, то эта задача не релизится / не идёт дальше по цепочке пока тесты не исправлены и не пройдены.
В этом плане у нас провило такое как для юнит тестов - тесты не прошлли значит дальше нельзя.
А вы успеваете? Ведь обычно на практике UI тесты запаздывают на одну итерацию (если используется agile).
Ну так и проапгрейдили тесты после падения. Или я что-то недопонимаю.
Если разработка на стадии, когда с каждым релизом все капитально меняется, то тут нужно с разработчиками договариваться, чтобы чендж-лист вам давали перед релизом. Ну и написать серию дымовых тестов, которые какие-то базовые вещи проверяют. И не запускать регрессию, пока они не пройдут.
Используем agile.
У нас правка UI тестов как и юнит тестов является критерием закрытия задачи (Definition of Done).
Ведь согласитесь, что никто не будет закрывать задачу, если юнит тесты не прошли. Мы решили, что для UI тестов это тоже вполне справедливо.
Это что касается правки существующих тестов.
Написание новых UI тестов у нас либо идёт отдельной задачей либо добовляется как критерий выполнения к конкретной новой фиче/задаче/баг-фиксу. Следовательно в оценке учитываются время на саму задачу + время на UI тесты.
В будующем хотим, чтобы написания UI теста было критерием выполнения задачи по-умолчанию, но до этого пока далековато.
Спасибо, услышал мнения.
У нас код лежит в одном репозитории с тестами (и юнит-, и UI). Разработчики могут запустить тесты (все или выборочно) на своём компе перед коммитом. Потом Jenkins собирает все коммиты вместе каждые 15 минут и прогоняет все тесты. Отчёт дженкинса горит на большом телевизоре. Тесты краснеют - разрабы их сразу исправляют.
Это очень круто. Вам можно только позавидовать
Да, почему-то все обычно говорят, что “это фантастика”, “у нас это нереально” и т.д.
И мне это до сих пор непонятно, потому что это совсем несложно. На самом деле гораздо проще, чем ваша нынешняя система.
testomat.io управление авто тестами