Интересная тема про то, как обращаться к элементам.
Не попало в статью, но мы договорились в таком порядке:
cy.get('[data-action-name=«connectionInfo»]')
cy.get('#user-name')
cy.get('[name=send]')
пойди и добавь data-attribute элементу
Привязка к верстке и CSS звучит нездорово. Мы не хотим, чтобы человек, который у нас занимается версткой, был вынужден исправлять тесты. У нас был печальный опыт в прошлом, кажется, ради поддержки скругленности в старом IE, кнопки оборачивались в кучу лишних элементов, а когда поддержка прекратилась, тесты не позволили легко переверстать компоненты.
Использование XPath как раз намекает на тесную связь с версткой.
В нашем проекте, я не вижу проблемы в дополнительных HTML-атрибутах, которые попадут в продакшн, но в других проектах это может потребовать специальной сборки, а для продакшна можно их удалять.
Интересной альтернативой может быть Testing Library — это заслуживает отдельной статьи и не всем подойдет.
Мы не хотим делать завязку на текст в интерфейсе, по той же причине — коммиты от технических писателей не должны приводить к поломкам тестов.
Можно реализовать PageObject через Cypress.Commands.add, создавая команду для каждого элемента на странице, но выглядит ужасно. Придется делать уникальные префиксы, чтобы не пересекаться с другими страницами.
Разница в идеологии: описывать все страницы в виде объектов кода vs. добавить минимально необходимый набор базовых функций.
Никто не говорит, что Selenium (или другая реализация протокола WebDriver) сама по себе является причиной флаки. Главная причина в том коде, который ее использует. А это миллионы строк, которые сами себя не перепишут. Мы около года целенаправленно боролись с флаки в этом направлении, но каждую итерацию оглядывались назад и понимали, что мы подметаем пустыню. Как оказалось, начинать заново без Selenium-a намного приятнее и возвращаться обратно уже не хочется.
Про отсутствующие фичи пишут в каждой статье про Cypress, вот официальная страница: docs.cypress.io/guides/references/trade-offs большинство из них заложены архитектурно. Да, нужно их осознать и решить насколько фреймворк применим в конкретном проекте.
Статья про уход от PageObject: www.cypress.io/blog/2019/01/03/stop-using-page-objects-and-start-using-app-actions
Для часто повторяющихся операций, таких как логин и создание некоторых объектов используем команды: Cypress.Commands.add(...)
Важно, что команды добавляются глобально, нельзя в двух тестах сделать разные clickSubmit команды. Поэтому добавляем их в support/commands.js и стараемся не устроить там помойку.
Когда возникает дублирование внутри тест-сьюта (спеки), то прям там объявляем функции.
Для тестов легкое (не массовое) дублирование кода кажется очень даже приемлемым, если это идет на пользу читаемости.
Zero downtime — это громкое заявление, боюсь, не все приложения к этому готовы. Если тренироваться на кошках, то работает. А реальные приложения накладывают существенные ограничения — в такой схеме деплоя, насколько я понимаю, старый код обязан корректно работать с новой схемой данных.
Спасибо за ссылки, интересные проекты.
Думаю, что по объему необходимого кода (или конфига) они все сопоставимы, вопрос гибкости для конкретной задачи.
Еще в копилку «знали бы раньше»: github.com/centrifugal/centrifugo
Не попало в статью, но мы договорились в таком порядке:
Привязка к верстке и CSS звучит нездорово. Мы не хотим, чтобы человек, который у нас занимается версткой, был вынужден исправлять тесты. У нас был печальный опыт в прошлом, кажется, ради поддержки скругленности в старом IE, кнопки оборачивались в кучу лишних элементов, а когда поддержка прекратилась, тесты не позволили легко переверстать компоненты.
Использование XPath как раз намекает на тесную связь с версткой.
В нашем проекте, я не вижу проблемы в дополнительных HTML-атрибутах, которые попадут в продакшн, но в других проектах это может потребовать специальной сборки, а для продакшна можно их удалять.
Интересной альтернативой может быть Testing Library — это заслуживает отдельной статьи и не всем подойдет.
Мы не хотим делать завязку на текст в интерфейсе, по той же причине — коммиты от технических писателей не должны приводить к поломкам тестов.
Разница в идеологии: описывать все страницы в виде объектов кода vs. добавить минимально необходимый набор базовых функций.
Про отсутствующие фичи пишут в каждой статье про Cypress, вот официальная страница: docs.cypress.io/guides/references/trade-offs большинство из них заложены архитектурно. Да, нужно их осознать и решить насколько фреймворк применим в конкретном проекте.
Для часто повторяющихся операций, таких как логин и создание некоторых объектов используем команды: Cypress.Commands.add(...)
Важно, что команды добавляются глобально, нельзя в двух тестах сделать разные clickSubmit команды. Поэтому добавляем их в support/commands.js и стараемся не устроить там помойку.
Когда возникает дублирование внутри тест-сьюта (спеки), то прям там объявляем функции.
Для тестов легкое (не массовое) дублирование кода кажется очень даже приемлемым, если это идет на пользу читаемости.
Думаю, что по объему необходимого кода (или конфига) они все сопоставимы, вопрос гибкости для конкретной задачи.
Еще в копилку «знали бы раньше»: github.com/centrifugal/centrifugo