Как стать автором
Обновить
10
0
Евгений Казаков @ekazakov

Программист

Отправить сообщение
Интересная тема про то, как обращаться к элементам.
Не попало в статью, но мы договорились в таком порядке:
  1. cy.get('[data-action-name=«connectionInfo»]')
  2. cy.get('#user-name')
  3. cy.get('[name=send]')
  4. пойди и добавь 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
В своей документации Амазон также предлагает использовать IP адреса, с вот таким комментарием:
We rarely change the IP addresses of name servers; if we need to change IP addresses, we'll notify you in advance.

Информация

В рейтинге
Не участвует
Откуда
Köln, Nordrhein-Westfalen, Германия
Дата рождения
Зарегистрирован
Активность