Спасибо за статью! Достаточно много пользовался Selenium и различными фреймворками «вокруг его», но в итоге перешёл к подходу, в котором webpack в тестовую сборку пакует набор тестов, написанных на javascript. Набор тестов может быть запущен как вручную тестировщиком прямо с web-интерфейса, так и автоматическим параметром при настройке сборки (спец. сборка webpack'ом для jenkins, например).
При автоматическом запуске, браузер стартовал c Node скрипта, который в итоге ожидал, что фронт пришлёт ему результаты прохождения тестов.
Как раннер использовал mocha, но к нему особо привязан не был, можно использовать какой вам угодно.
Для упрощения работы с интерфейсом чистым javascript'ом использовал вот такую поделку github.com/evegreen/useractions
Из плюсов:
Я почти перестал писать явно ожидание каких-либо используемых мною далее элементов на странице, так как useractions автоматически перед любым действием ждал их (реализация похожа на FluentWait)
При сравнении с идентичными тестами на Selenium я получил прирост в скорости в 15 раз (в среднем) (и это при том, что в тестах на Selenium везде использовался FluentWait!)
Тесты работали абсолютно идентично в Chrome, Chrome для Android и Firefox без каких-либо танцев с бубном (уверен, что и в других актуальных браузерах всё заведётся так же).
Из минусов (субъективно):
Тестировщикам пришлось писать тесты на JS, а это им далось сложнее, чем к примеру на Java / Python + Selenium
При автоматическом запуске, браузер стартовал c Node скрипта, который в итоге ожидал, что фронт пришлёт ему результаты прохождения тестов.
Как раннер использовал mocha, но к нему особо привязан не был, можно использовать какой вам угодно.
Для упрощения работы с интерфейсом чистым javascript'ом использовал вот такую поделку github.com/evegreen/useractions
Из плюсов:
Из минусов (субъективно):