Playwright или Selenium?

[@Rabestro]

Интересно, на сколько подходит для ваших целей Spock Framework + Geb?

[@alex_smite]

Не пробовали, нам Selenium и Playwright за глаза

[@AlexeyALV]

А почему рассматривали Selenium, а не Selenide?
Кроме того, надо обращать внимание на способы запуска и получения отчетов. Есть ли необходимость делать автоматизированный регресс, например, если у вас регулярные релизы. Нужно ли распараллеливание запусков. Надо ли увязывать последовательность запусков разных тестов во времени.

[@alex_smite]

Selenium IDE, если правильно понял, обладает теми же недостатками в плане shadowdom и dragAndDrop. К тому же работать из кода значительно быстрее и привычнее. И да, у нас была необходимость делать автоматизированный регресс

[@aslk]

Selenide != Selenium IDE

ссылка на фреймворк https://ru.selenide.org/

[@EreminD]

Selenide - библиотека на java. В статье говорится, что стек проекта - C# и TS.
В общем selenide здесь неуместен

Хотя, даже если есть какой-то порт селенида на .net, тут все равно нет претензий к селениуму, которые закрываются именно селенидом

[@alex_smite]

Стек: c#, angular ts. Рассматривали ближе к этим языкам

[@ValeriaFatekhova]

По поводу перетаскивания: у себениума имеется с ним баг. Недавно смотрела презентацию библиотеки для питона Selenium tools вроде, в ней есть решение данной проблемы. У библиотеки открытый код, можно посмотреть и сделать подобный фикс для С# (из статьи я поняла, что тесты будут на нем)

[@daemonyeen]

Cypress

[@alex_smite]

см. ниже ("Cypress и Puppeteer -- JS only ")

[@dabrahabra]

Написание тестов в современной разработке играет одну из самых важных и неотъемлемых этапов разработки современного программного обеспечения.

Кмк это попахивает «ошибкой выжившего» 

[@alex_smite]

Всегда было интересно, к чему такие комментарии?

[@dabrahabra]

1. Многие успешные стартапы и MVP начинали без тестов. Они выигрывали за счёт скорости, гибкости и прямой обратной связи от пользователей.

2. Тесты не гарантируют качество. Плохие или формальные тесты создают ложное чувство безопасности.

3. Высокая стоимость поддержки. В быстро меняющихся проектах тесты часто устаревают быстрее, чем код.

4. Не всегда тесты приносят ценность. В прототипах, одноразовых скриптах или исследовательских проектах написание тестов может быть пустой тратой времени.

5. Культура тестирования — следствие, а не причина успеха. Компании, ставшие зрелыми, внедряют тесты, когда процессы стабил изировались.

[@alex_smite]

Абсолютно согласен, из чего могу сделать вывод: если вы хотите стабилизировать код, которым пользуетесь не только вы и который меняется не часто (скажем не чаще, чем раз в месяц), а также в нем достаточно много кода, тесты вам подходят, однако лучше всего написать тесты которые или который покрывает весь сценарий

[@i360u]

Странные альтернативы рассматриваются. А почему не Cypress и Puppeteer?

[@vabka]

А разве Playwright - это не "Как Puppieteer, только лучше"?

[@conopus]

Cypress и Puppeteer -- JS only. А для Playwright код можно писать на JavaScript, Python, Java, .NET — также как и для Selenium. И, да - он разрабатывается автором Puppeteer.

[@alex_smite]

Сами тесты пишут разработчики, которые больше ориентируются в c#

[@polRk]

А почему нет поддержки сафари, когда есть?

[@alex_smite]

Чистого сафари нет https://playwright.dev/docs/browsers