Comments 18
Вопрос по поводу Page Object. В какую сторону пошли ?
Для часто повторяющихся операций, таких как логин и создание некоторых объектов используем команды: Cypress.Commands.add(...)
Важно, что команды добавляются глобально, нельзя в двух тестах сделать разные clickSubmit команды. Поэтому добавляем их в support/commands.js и стараемся не устроить там помойку.
Когда возникает дублирование внутри тест-сьюта (спеки), то прям там объявляем функции.
Для тестов легкое (не массовое) дублирование кода кажется очень даже приемлемым, если это идет на пользу читаемости.
Чем Cypress.Commands.add отличается от PageObject? По сути это одно и тоже.
Разница в идеологии: описывать все страницы в виде объектов кода vs. добавить минимально необходимый набор базовых функций.
Спасибо. Полгода в табличке "Для развития" висела задача "разобраться с Cypress". Без вас бы ещё полгода точно висела)
Стандартные заблуждения про Selenium, которые кочуют в каждую статью про Cypress. Не могу не разобрать:
Selenium WebDriver — это third-party сервис на Java
Не обязательно. WebDriver – это протокол, его можно реализовать на чем угодно. Например, есть версия на Go. Также можно запустить бинарник chromedriver или geckodriver напрямую, и никакой Java там не нужно.
Сетевое взаимодействие также вносит свой вклад во время выполнения тестов.
Если запускать локально, то никакого взаимодействия не будет. А если Cypress запустить в режиме Dashboard, то и там тоже появится сетевое взаимодействие. Так что это совсем не от инструмента зависит.
Ну и наконец, если открыть список багов cypress, отсортированный по лайкам, то можно увидеть много важных вещей, которые Cypress не умеет (подержка клавиатурных событий, ховер-состояния элементов, кросс-доменное взаимодействие и айфреймы). Эти баги открыты годами, и скорого решения не ожидается. Тут становится вообще непонятно, зачем разработчики ввязываются в инструмент с такими ограничениями.
Справедливости ради, у нас не только заблуждения по поводу Selenium, но и 15-летняя практика его использования с 2006 года, тысячи написаных тестов и несколько продуктов, которые подвергались тестированию им. Используем мы, конечно, и Selenoid для автопрогонов. Практика использования Cypress — примерно 2 года. Начинали эксперименты в рамках research days, далее были небольшие проекты и дошли до активного внедрения в основном продукте. Мы спрашивали внутри команды и люди реально говорят, что им нравится и удобно создавать тесты с использованием Cypress. Также мы пробовали писать тестами силами совершенно разных людей и время на погружение довольно маленькое, где не последнюю роль играет удобство отладки и all batteries included.
Тут становится вообще непонятно, зачем разработчики ввязываются в инструмент с такими ограничениями.
Наверное, потому что мы не искали целенаправлено "что же не работает", а взяли некоторые текущие проекты и задачи и попробовали написать ряд тестов, чтобы увидеть плюсы и минусы именно в нашем контексте.
Не обязательно. WebDriver – это протокол
Чисто технически, Selenium WebDriver — это просто полное название продукта, который написан на Java. Так что в упомянутой фразе — все верно )
Остается нераскрытым вопрос, насколько оправдано внедрение нового инструмента. Если основная причина непринятия Selenium - нестабильные тесты, так может просто подкрутить инфраструктуру, сделать их более стабильными и удобными в отладке? Это делается несложно, не какой-то rocket science.
Кроме того, а что насчет вендор-лока в Cypress? Его тесты невозможно портировать никуда, они уже 5 лет не могут добавить поддержку Jest. Более того, Cypress разрабатывается маленьким стартапом, есть шанс что они разорятся и проект превратится в тыкву, что вы будете делать в этом случае?
Если основная причина непринятия Selenium — нестабильные тесты
Нет, в первую очередь — это скорость разработки, стоимость поддержки и удобство. Наши тесты для Selenium были исторически на PHP. Как обычно, все вокруг за годы обросло говном вспомогательными инструментами, helper'ами и даже иерархиями классов :) Но даже если все это убрать и пробовать начинать с нуля в новом проекте, то все равно оказывается с Cypress'ом удобнее. Вы скажете, что это субъективщина и будете правы. В конце концов, мы же просто своим опытом делимся.
Кроме того, а что насчет вендор-лока в Cypress?
Он open source под MIT. Имхо, это не более опасный вендор-лок, чем с Selenium. В конце-концов, где-то ~2004-2005 мы выкинули e2e тесты на Perl'е и пошли в сторону Selenium. Иногда это вполне полезно — заменять внутренние инструменты, если прошлый инструмент перестал чем-то устраивать :)
Имхо, это не более опасный вендор-лок, чем с Selenium
Вебдрайверы для браузеров пишут сами разработчики этих браузеров, и их код лежит рядом и собирается с основными исходниками. Таким образом, для каждой новой версии Хрома (или другого браузера) априори будет совместимая версия драйвера.
В случае Cypress вы зависите от их цикла обновлений. Забросят они проект – и вы останетесь у разбитого корыта с устаревшим браузером. Помните, были такие PhantomJS и CasperJS? Вот тут заложены те же самые грабли.
В Cypress из хорошего только встроеный браузер — нет проблем как подружить браузер, вебдрайвер, версию библиотеки и старые тесты.
Из плохого же:
- без PageObject тесты не читаются
Что автор теста хотел проверить? Развеcy.get('[data-test=MultiOffer--button]') .last() .click(); cy.wait('@preview'); cy.get('[data-test=Confirm]') .should('be.exist'); cy.get('[data-test=Upsell--upsellAccept]') .click(); cy.get('[data-test=Uupsell--upsellConfirm]') .click(); cy.wait('@buy'); cy.wait('@activeKeys'); cy.get('.pul-toast--success') .should('be.visible') .contains('Plesk Web Admin Edition') .contains('PLSK.04663074.0006') .contains('Plesk Web Host Edition');
хуже?license_info = self.license_info.open_bind_to_ip_window().bind_to_ip(ip_v6) success_message = license_info.message_box.get_info_message_text() expected_message = BindingToIpMessages.LICENSE_BOUND_TO_IP % (self.plesk_license.keyNumber, ip_v6) self.assertEqual(success_message, expected_message) - Компоненты можно искать только по CSS, Приходилось специально добавлять в прод окружение элементы, чтобы зацепиться за них в Cypress. Xpath гораздо богаче и более гибкий.
- Про отладку тоже не все было гладко, деталей уже не припомню
Конечно это все было года 2 назад уже. Тесты были страшнее, чем то что привел выше, возможно и Cypress допилили. Для unit testing фронта вроде норм, для end-2-end я бы не взял.
А что из плохого? Коммент оборвался на самом интересном месте :)
del
Как замену PageObject можно использовать commands.js из каталога support
В этом файле можно определить свои команды и использовать их для выполнения повторяющихся задач (поддерживаются параметры, как в обычных функциях).
Тот же самый логин через форму авторизации - самое первое что я сделал.
У меня переход на страницу авторизации и вход в систему выполняется в тестах как cy.login(userData)
Не попало в статью, но мы договорились в таком порядке:
- cy.get('[data-action-name=«connectionInfo»]')
- cy.get('#user-name')
- cy.get('[name=send]')
- пойди и добавь data-attribute элементу
Привязка к верстке и CSS звучит нездорово. Мы не хотим, чтобы человек, который у нас занимается версткой, был вынужден исправлять тесты. У нас был печальный опыт в прошлом, кажется, ради поддержки скругленности в старом IE, кнопки оборачивались в кучу лишних элементов, а когда поддержка прекратилась, тесты не позволили легко переверстать компоненты.
Использование XPath как раз намекает на тесную связь с версткой.
В нашем проекте, я не вижу проблемы в дополнительных HTML-атрибутах, которые попадут в продакшн, но в других проектах это может потребовать специальной сборки, а для продакшна можно их удалять.
Интересной альтернативой может быть Testing Library — это заслуживает отдельной статьи и не всем подойдет.
Мы не хотим делать завязку на текст в интерфейсе, по той же причине — коммиты от технических писателей не должны приводить к поломкам тестов.
Про отсутствующие фичи пишут в каждой статье про Cypress, вот официальная страница: docs.cypress.io/guides/references/trade-offs большинство из них заложены архитектурно. Да, нужно их осознать и решить насколько фреймворк применим в конкретном проекте.
>Код тестов пишется на JavaScript
А можно еще и на TS)
Мне он нужен для автоматизации реальных химических тестов воды на ряд параметров, но софтина для тестов не имеет никакого API, и Cypress headless + Github Actions тут пришелся в самый раз.
Единственная претензия к docker образу Cypress — он весит 1.1GB и для запуска мелких тестов это немного overkill.
Cypress и его место в нашей тестовой пирамиде