testomat.io управление авто тестамиЯ бы не начинал с UI тестов, плохой подход. Лучше начните с API тестов, больше пользы будет ИМХО. Бегут быстрее, пишутся проще, многопоточность обеспечивается JUnit / TestNG из коробки, не надо придумывать все эти обходы кукис для нескольких сессий на 1 машине.
Как добьётесь норм покрытия на этом уровне - переходите к UI.
Почему так - патамуша пирамида тестов.
А совсем по-хорошему- если есть возможность, начните с проверки компонентных тестов разрабов, если они их вообще пишут.
1 лайк
Рекомендую использовать webdriver io, есть все из коробки, плюс любая интеграция с alure,docker и тд и тп. Boilerplate Projects | WebdriverIO
Готовая коробка GitHub - webdriverio/cucumber-boilerplate: Boilerplate project to run WebdriverIO tests with Cucumber, можно брать и сразу использовать. 150+ базовых шагов уже внутри + если надо добавите свои.
Плюсы: typescript + неограниченный запуск разных потоков (лишь бы машина тянула)+ очень много плагинов (большое комюнити)+ очень легко вкатиться даже с нуля. Лучше варианта для того чтобы не сильно заморачиваться и результат был завтра пока не встречалось.
1 лайк
А оправдано ли использование moon?
без moon можно задействовать все потоки(у нас 8) и за 20 минут гоняется в пару раз больше тестов
Добрый День.
Как мы можем паралелить тесты с Playwright, это в клауде Moon или на тачке сервере(где тут проц, с N-Ядер, каждое ядро умеет N-Потоков).
На данный момент мы используем 1 вариант Moon. Moon поддерживает Playwright, Moon икапсулирует в себе Selenoid, единственное что есть ограничения бесплатной версии.
В случае использование Selenium or Selenide, разворачиваем Selenoid хоть в клауде хоть дома.
Тут уже ограничение ресурсов на другом уровне.
Спасибо большое, у вас очень интересный опыт! днако пока все же начала в известной мне связке работать. Возможно, в будущем будем менять стек либо на другом проекте пригодится, буду знать, к кому обращаться 
Благодарю! Под мобилки интересно с расчетом на будущее текущего проекта
Ваше наблюдение звучит очень логично! Однако я выше вероятно не указала, что бэк у нас java, фронт на JS, есть еще часть на php между фронтом и бэком. Вероятно потому “сверху” и хотели человека с опытом на java.
А разве в Selenide ожидания не удобно прописаны? есть shouldBe(Condition.visible), правда пока не вникала в детали
Не совсем поняла идею с точки зрения реализации. Возможно, вам попадались хорошие примеры на гитхабе?
Понимаю вашу концепцию, но не всегда есть возможность ввиду разных причин делать так, как правильно. Потому, идем по пирамиде в другом направлении
да нет, вы выше всо понятно описали: бэк на джаве, фронт на js, есть упрямое руководство которое что-то там диктует. я критикую сам подход писать разные части TA пирамиды на разных языках а потом пытаться все это интегрировать и встроить в пайплан (а есть еще проблема поддержки разных версий приложения, например. как будете решать? а были бы все тесты в том же репозитории, что и фронтенд, этой головной боли вообще бы не было)