Архитектура тестов или с чего вообще начать (тестировать JS на JAVA)

Теги: #<Tag:0x00007f78e2341ef0> #<Tag:0x00007f78e2341e28> #<Tag:0x00007f78e2341d10> #<Tag:0x00007f78e2341c20> #<Tag:0x00007f78e2341b08> #<Tag:0x00007f78e2341a40> #<Tag:0x00007f78e2341928> #<Tag:0x00007f78e2341860> #<Tag:0x00007f78e2341770>

Я бы не начинал с UI тестов, плохой подход. Лучше начните с API тестов, больше пользы будет ИМХО. Бегут быстрее, пишутся проще, многопоточность обеспечивается JUnit / TestNG из коробки, не надо придумывать все эти обходы кукис для нескольких сессий на 1 машине.
Как добьётесь норм покрытия на этом уровне - переходите к UI.
Почему так - патамуша пирамида тестов.
А совсем по-хорошему- если есть возможность, начните с проверки компонентных тестов разрабов, если они их вообще пишут.

1 симпатия

Рекомендую использовать webdriver io, есть все из коробки, плюс любая интеграция с alure,docker и тд и тп. https://webdriver.io/docs/boilerplates#webdriveriocucumber-boilerplate

Готовая коробка https://github.com/webdriverio/cucumber-boilerplate, можно брать и сразу использовать. 150+ базовых шагов уже внутри + если надо добавите свои.

Плюсы: typescript + неограниченный запуск разных потоков (лишь бы машина тянула)+ очень много плагинов (большое комюнити)+ очень легко вкатиться даже с нуля. Лучше варианта для того чтобы не сильно заморачиваться и результат был завтра пока не встречалось.

1 симпатия

А оправдано ли использование moon?
без moon можно задействовать все потоки(у нас 8) и за 20 минут гоняется в пару раз больше тестов

Добрый День.
Как мы можем паралелить тесты с Playwright, это в клауде Moon или на тачке сервере(где тут проц, с N-Ядер, каждое ядро умеет N-Потоков).
На данный момент мы используем 1 вариант Moon. Moon поддерживает Playwright, Moon икапсулирует в себе Selenoid, единственное что есть ограничения бесплатной версии.

В случае использование Selenium or Selenide, разворачиваем Selenoid хоть в клауде хоть дома.
Тут уже ограничение ресурсов на другом уровне.

Спасибо большое, у вас очень интересный опыт! днако пока все же начала в известной мне связке работать. Возможно, в будущем будем менять стек либо на другом проекте пригодится, буду знать, к кому обращаться :slight_smile:

Благодарю! Под мобилки интересно с расчетом на будущее текущего проекта

Ваше наблюдение звучит очень логично! Однако я выше вероятно не указала, что бэк у нас java, фронт на JS, есть еще часть на php между фронтом и бэком. Вероятно потому “сверху” и хотели человека с опытом на java.
А разве в Selenide ожидания не удобно прописаны? есть shouldBe(Condition.visible), правда пока не вникала в детали

Не совсем поняла идею с точки зрения реализации. Возможно, вам попадались хорошие примеры на гитхабе?

Понимаю вашу концепцию, но не всегда есть возможность ввиду разных причин делать так, как правильно. Потому, идем по пирамиде в другом направлении :slight_smile:

да нет, вы выше всо понятно описали: бэк на джаве, фронт на js, есть упрямое руководство которое что-то там диктует. я критикую сам подход писать разные части TA пирамиды на разных языках а потом пытаться все это интегрировать и встроить в пайплан (а есть еще проблема поддержки разных версий приложения, например. как будете решать? а были бы все тесты в том же репозитории, что и фронтенд, этой головной боли вообще бы не было)