Сравнение тестовых фреймворков: Cypress vs Playwright vs Selenium

[AndyStatic]

«Смешались в кучу кони, люди» (с)

Cucumber это надстройка, можно его в Playwright прикрутить. И через пару костылей в Cypress.

"Cypress — подходит для быстрого старта и проектов на JavaScript/TypeScript". C Playwright  можешь стартануть за 10 минут. Две комманды на setup + запись первого теста череp рекордер или агента и гоняй для демки менеджерам сколько хочешь.

Статья явно AI. И ее не ревьювил QA. B вообще когда сравниваете фреймворки для теста, то уже просто фреймворки сравнивать это бесплазеное занятие. И таких статей на хабре пара тысяч. Нужна связка язык + фреймворк. Например все 3 сравнить только на TypeScript. А то, давайте все использовать Cypress, когда 100% комманды пишет все на Java, это как-то не очень идея.

[TITnet]

А то, давайте все использовать Cypress, когда 100% комманды пишет все на Java, это как-то не очень идея.

Вполне себе идея. Команда на Java пишет код фронта/бека, а QA вполне могут писать на любом другом языке. Если мы не говорим о том, чтобы QA писали unit-тесты, конечно.

[AndyStatic]

По моему опыту, вот основные плюсы одного и того‑же языка для кода приложения и тестового кода:

3. e2e/UI тестовый код хранится рядом с кодом приложения, и девелоперы гоняют тесты локально перед мердж реквестами, чтоб локально проверить баг или фичу. Экономит время на пинг понге с билдами, деплоями, и перестаскиванием тикетов туда‑сюда.

4. Тестовый код помогает создавать сложные тестовые данные, осоебнно в e‑commerce/финтех, например персонажа с кучей платежей и ордеров в разные периоды времени. Девелоперу чтоб повторить, а затем пофиксить баг связанный с созданием таких тестовых данных тоже нужно уметь запускать тесты локально. А иногда создавать свои специфичиские сценарии, и дебажить падения. Предпочтительно чтоб это было без переключения репозитория или языков/фреймворков.

5. Бывают компании с 1 QA на 20 devs, где devs сами пишут авто‑тесты, а QA больше напрвляет какие тесты нужны.

[TITnet]

Уважаемый автор, вы сами пробовали писать тесты на этих фреймворках? Или хотя бы изучить их?

• Нет поддержки Safari.

Она есть. Пока в режиме эксперимента, но есть.
https://docs.cypress.io/app/references/launching-browsers#WebKit-Experimental

Он не умеет из коробки параллелить тесты.

Как это не умеет, когда делает это прекрасно и из коробки, конечно.

https://docs.cypress.io/cloud/features/smart-orchestration/parallelization

У меня over 1000 тестов прекрасно работают на шести параллельных воркерах, и в сумме экономят примерно 5/6 времени, если бы прогон был на одной машине.

Также, конечно, нельзя не сказать про Cypress Dashboard. Проблема в том, что мы отдаем обрабатывать наши тесты стороннему сервису. Это весьма небезопасно, и не приветствуется в крупных компаниях, а также при работе в финансовом секторе.

Во-первых, Cypress давно переименовал свой продукт из Cypress Dashboard в Cypress Cloud.
Во-вторых, у Cypress есть все необходимые сертификаты безопасности. Они отлично проходят vendor management для compliance-ориентированных компаний.

Недостатки Cypress

• Ограниченная поддержка браузеров.

• Нет поддержки Safari и мобильных устройств.

• Ограниченная параллельность выполнения тестов.

Поддержка Safari есть. Параллельность тоже есть.
Вы написали, что Cypress не поддерживает мобильные устройства.
Но их в полной мере и Playwright не поддерживает. Т. к. эти фреймворки заточены на web-тестирование в первую очередь.

Cypress — подходит для быстрого старта и проектов на JavaScript/TypeScript.

Cypress подходит не только для быстрого старта. У меня проекты на нём по 7000 E2E UI тестов, и отлично всё работает.
Язык тестируемой системы не имеет значения при выборе языка для автоматизации тестирования...

У Cypress есть свои недостатки, о которых вы умолчали в статье.
Одновкладочное тестирование (пока).
При сложных тестах имеем pyramid of doom, но с этим вполне можно жить.

[sickfar]

В заголовке селениум, в тексте про селенийм упоминается только в контексте кукумбера - который вообще непонятно как сюда влез.