Доброго времени суток, коллеги!
Нужен совет по следующей ситуации:
Дано:
Selenide 2.23
JUnit
Allure
Jenkins (удаленный сервер под управление unix системы)
100 UI тестов.
FireFox - 38.3.0 esr
Maven
При выполнении тестов локально, проблемы, вроде, не возникают. Все елементы находятся. Как только запускаю тесты удаленно в параллельном режиме (параллелизация по классам, 10 потоков) ИНОГДА возникают ситуации, что некоторые елементы просто не находятся.
Местами ситуация доходит до смешного: имеется 20 тестов, которые используют абсолютно одни и те же елементы. Так вот, 19 из них выполнится без вопросов, а один может упасть. При повторных перезапусках могут отработать все, а может упасть другой тест (или пара) по той же причине (бывает, что не найдены разные елементы).
Такая нестабильность просто… ну вы меня поняли
И нет никакой системы в падениях! Сейчас упали одни - перезапустился - все норм, еще раз - все норм, на третий что-то да отвалится… Такое ощущение, что вопрос в самом FireFox, тип когда их много то им надо дольше времени на “подумать”.
Добавлю лишь, что все ожидания - динамические (спасибо Selenide) и, опять же, локально или в одном потоке к ним претензий нет (вроде…).
У кого есть идее, подскажите в чем может быть дело?
10 одновременно работающих браузеров - очень ресурсоёмкое мероприятие (конечно, ещё от приложения зависит, если и оно не лёгкое, то тем более). Уменьшайте количество одновременных потоков. Либо смотрите чего не хватает в ресурсах - диска, памяти, проца.
Да, верное замечание.
Либо попробуйте параллелить на более “жирной” машине либо же выносить в грид. Т.к. очень вероятно, что в текущей реализации бывают подтормаживания браузера и поэтому драйвер не может что-то найти.
Чтобы избавиться от “вроде” в локально, то поднимите виртуалку с конфигурацией схожей с удалённой и запустите хотя бы раз 10 тесты к ряду, чтобы понять, падают или нет…
Do different tests instead of repeating the same tests
Что ж, спасибо всем откликнувшимся, судя по всему проблема не носит глобальный характер, значит надо пробовать разные варианты, в т.ч., указанные выше. Буду копать.
А каким образом происходит доступ к элементам страницы? Напрямую или через PageObject?
Если напрямую, то такое поведение может быть слествием самодеятельности браузера по сборке мусора и оптимизации DOM. В этом случае PageObject может помочь.
Я использую PageFactory. Все веб елементы объявлены с аннотацией @FindBy и, на сколько я понимаю принцип работы етого механизма, их поиск происходит в момент обращения теста к етому елементу.
Напрямую или через PageObject?
Мне не совсем понятен етот вопрос… В чем разница доступа на прямую и через пейджу? Что в первом то и во втором случае поиск все равно осуществляется драйвером в момент, когда страница “дала команду” что она загрузилась. Или мое представление не правильное?
Остается еще грешить на плагин, который “натягивает” верстку на елементы, но с другой стороны, если елемент уже в доме и имеет статус visible, какая ему разница что там плагин делает… Если, конечно, плагин не изменяет статус елемента…
Вдруг найдете решение - делитесь, пожалуйста.
Очень похожая проблема у нас. Набор такой же, только Thucydides вместо Selenide.
На локальных машинах тесты проходят успешно, запущенные с дженкинса - падают с ошибкой
AssertionError: org.openqa.selenium.NoSuchElementException: Timed out after 30 seconds. Unable to locate the element: Element is not usable [[RemoteWebDriver: firefox on WINDOWS (ec97b964-b3c3-4c7c-921d-6e041a50d3bc)] -> id: some-id-here]
На скриншоте элемент уже отрисован, вряд ли цсс не успевает подтянуться.
Были догадки, что проблема с совместимостью версий селениума и файрфокса, но эксперименты с версиями пока устойчивых результатов не принесли.
Действительно, вы слишком много хотите от компьютера. 10 поток - это черезчур. Почему не 100?
Кстати, мне вот всегда интересно было. Вы уверены, что именно тесты - самая медленная часть, т.е. параллелить стоит именно тесты? Эти 10 браузеров ведь обращаются к одному приложению, а оно лезет в одну базу данных? И следовательно, если дёргать приложение из 10 браузеров, быстрее оно не станет. Тормозить будет точно так же (точнее, даже больше).
Тестируемое веб-приложение стоит на мощном сервере, и к нему (в т.ч. и базам которые оно использует) ежесекундно обращается гораздо больше реальных пользователей, чем то количество что эмитируют мои тесты. Даже в параллели 10 потоков.
Машина с Jenkins и тестеми - оренда на Amazon, там железо без претензий…
Учитывая изложенное, у меня подозрения что вопрос именно в тестах. Возможно даже в WebDriver или самом FireFox. Но вот что именно и как ето “лечить”. Неисключено что независимо от “мощности” железа ето можно вылечить только уменьшением количества потоков.
Андрей, а в твоей практике какой стабильный придел потоков для параллельного запуска тестов?
Когда я работал с сусиком, то, как не странно, решал аналогичную проблему снижением количества потоков.
Но у меня тогда не было таких ресурсов, какими я располагаю сейчас.
Попробуйте, может получится…
Коллеги, еще такой вопрос по теме:
что если для повышения стабильности тестов подымать грид (локально)?
Я никогда с гридом не работал, но судя по литературе - он специально разработан для запуска большого количества разных браузеров. Возможно ета его особенность поможет решить вопрос?
Если не хотите интерекшенов - запускайте ваши браузеры в докер контейнерах. На гитхабе селениума уже лежат докерфайлы образов, все что нужно сделать это установить докер на машины и запустить контейнеры, ну и указать тестам путь к гриду.
1 контейнер 1 браузер 1 поток - все изолированно, никаких интерекшенов.
Легко маштабировать
А гонять на одной тачке 100 браузеров друг на дружке это полная жопа