Это краткое изложение и личное мнение о некоторых лучших практиках Cypress.

Используйте атрибут data- для выбора элементов

Приоритизация этих команд/селекторов (от высокого к низкому) в этом порядке при поиске чего-либо на странице.

cy.findByRole › data- ›= cy.contains › другое

Хотя Cypress поощряет использование data-*, я думаю, что cypress-testing-library может превосходить все вышеперечисленное, поскольку его команда запроса (cy.findByRole и т. д.) ищет вещи с точки зрения реального пользователя. Причина та же, что и в Руководстве по библиотеке тестирования.

Одним из примеров этой команды может быть:

Если cy.contains(some-text) some-text критично, что не должно меняться, то идите на это, чем на data-

Утверждение не всегда требуется для действительного теста.

Многие команды построены с утверждением.

Команды с утверждением являются частью поведения пользователя, поэтому cy.get('my-button').should('exist') довольно избыточен.

cy.visit очень медленный

Порядок трудоемких тестов от медленного к быстрому:

  1. Каждое cy.visit(): отключение, подключение, выборка или повторное использование кеша, компиляция, Function call ~1300 мс 🐢🐢🐢🐢🐢
  2. Каждая замена горячего модуля webpack: ~200 мс 🐢🐢
  3. Многие cy.type(): каждое нажатие клавиши занимает 10 мс (настраивается), средний символ модульного теста ‹ 100 символов 🐢
  4. Каждый тестовый пример: перезапустите некоторый контекст тестирования кипариса ‹100 мс 🐢

Иногда cy.visit() используется только для сброса состояния компонента. В этом случае вы можете просто снова смонтировать компонент, чтобы сбросить его состояние. Обернув свой компонент в тривиальный элемент и изменив ключ элемента-оболочки (или вы также можете изменить ключ своего компонента). Например:

Тесты не должны полагаться на предыдущее состояние теста

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

Но в кипарисе альтернативой является объединение тех тестов, которые зависят от предыдущего состояния теста. Причины для этого:

  1. Вы не потеряете состояние (экран, DOM) вашей цели тестирования, даже если она сломается в середине длинного теста. 🤘интерактивный пользовательский интерфейс/машина времени потрясающие 🤘
  2. Чем больше ваши тесты походят на то, как используется ваше программное обеспечение, тем больше уверенности они могут дать вам. Кент. Додд
    Если тест терпит неудачу только тогда, когда несколько шагов выполняются друг за другом, то это действительно проблема, и ее невозможно обнаружить, когда каждый тест предполагает, что обновление ч/б каждого шага работает так, как ожидалось.
  3. Чем меньше тестов, тем быстрее, потому что накладные расходы на инициализацию/удаление теста обычно намного медленнее, чем большее количество утверждений в одном тесте.

Антипаттерн: множество крошечных тестов, чтобы утверждать только одно

См. предыдущее тестовое состояние, пункт 3.

Более того, требуется ли по-прежнему проверка работоспособности макета для тех полей, с которыми вы в конечном итоге будете работать в последующих тестах? 🤔

Антипаттерн: использовать после/после каждого

Он считается анти-шаблоном по следующим причинам:

  1. Висячее состояние после каждого теста (будь то успешное или неудачное) — это бесценная часть для изучения вашей проблемы.
    В других средах тестирования вы не получаете много данных для исследования после неудачного теста, поскольку они исчезают навсегда. Некоторые хорошие тестовые фреймворки могут рассказать вам об ожидаемой/фактической разнице или какой-то другой дополнительной информации, но ни один из них не сравним с интерактивным пользовательским интерфейсом Cypress, который точно сообщает вам, что происходит в каждой команде.
  2. В кипарисе afterEach НЕ запускается после неудачных тестов. after НЕ запускается при прерывании теста.

Антипаттерн: cy.wait()

Во многих случаях вам это не нужно, так как выполнение тестов занимает ненужное время по следующим причинам:

  1. Все команды запросов cypress DOM построены с повторной попыткой и тайм-аутом.
  2. Попробуйте определить некоторые изменения, которые пользователь должен заметить после определенного действия, вместо того, чтобы тратить время на ожидание.