Как лучше всего писать тесты e2e, которые нужно запускать последовательно?

Question

Мы находимся в процессе написания тестов e2e для нашего angular приложения с использованием Cypress.io. Проблема, с которой мы сталкиваемся, заключается в том, что, хотя мы знаем, что тесты не должны зависеть друг от друга, но на самом деле это кажется невозможным в реальном приложении. Предположим, пользователю необходимо выполнить следующие действия:

1. Регистрация
2. Вход
3. Создать категорию
4. Создать подкатегорию
5. Крит продукт в определенной c подкатегории

Теперь, если нам нужно написать тесты для этого сценария ios, нам придется либо написать один гигантский тест, который выполняет все это в одном go или найдите способ заставить их работать в последовательности, где, возможно, каждый следующий тест зависит от состояния, оставленного предыдущим. Мне любопытно, как все справляются с этой ситуацией, потому что я считаю, что она должна очень часто появляться в реальных корпоративных приложениях.

Answer 1

1. Регистрация
2. Вход
3. Создание категории
4. Создание подкатегории
5. Создание продукта в определенной c подпрограмме категория

Обычно, когда вы пишете тесты E2E, первое правило большого пальца заключается в том, что ваши тесты должны выполняться независимо и не должны зависеть от предыдущих тестов. Здесь вы выполняете независимые тесты, но в то же время вы выполняете вызов API для выполнения предварительных шагов (в случае входа в систему регистрация выполняется через API)

Таким образом, вы можете действовать, как показано ниже.

1. Тест записи для функциональности регистрации.

2. Теперь для теста входа в систему вы больше не будете выполнять процесс регистрации через пользовательский интерфейс. Итак, все, что вам нужно сделать, - это вызвать API, чтобы выполнить процесс SignUp.
   Причина: Ваш пользовательский интерфейс для SignUp UI мог сломаться, а остальные функции работают нормально. Таким образом, вы не будете использовать для этого UI-маршрут. Поэтому сделайте вызов API

3. Как упоминалось выше, вы будете выполнять вызовы API, чтобы выполнить 1-й и 2-й тестовые примеры, чтобы приземлиться для 3-го случая

4. Как упоминалось выше, вы будете выполнять вызовы API для выполнения 1-го, 2-го и 3-го тестовых примеров, чтобы выполнить 4-й случай

5. Как упоминалось выше, вы будете выполнять вызовы API для выполнения 1-го и 2-го & 3-й и 4-й тестовые примеры для 5-го случая

Answer 2

В основном то, что я буду делать, - это создать 5 тестовых файлов, включающих соответствующие тесты. Но к каждому тесту будут предъявляться разные требования. В вашем сценарии

• Регистрация - Нет зависимостей
• Вход - необходим зарегистрированный пользователь
• Создать категорию - требуется авторизованный пользователь
• Создать подкатегорию - Требуется зарегистрированный пользователь и созданная категория .. et c.

Я бы сделал,

• Следуйте объектной модели страницы, чтобы идентифицировать, хранить и извлекать элементы страницы
• иметь общее место для хранения методов / функций

Затем, если мы возьмем тестовый пример для Create категория

Как предварительные условия (перед каждым)

• Установите область просмотра
• войдите на страницу
• Перейдите к странице создания категории / section
• Veryfy URL-адрес

в тестовых случаях (it)

• добавит спецификации c тестовый сценарий ios, проверки и т. д. c как указано в тестовых примерах c для создания категории.

Причина кластеризации тестовых скриптов в том, что легко индивидуально проверить состав Ненты при необходимости. В противном случае тестовый файл будет огромным, и его будет очень сложно обновить, и, что наиболее важно, когда вы сделаете модификацию на Создайте подкатегорию , и если вы запустите автоматизацию, cypress будет go через все тестовые примеры, даже если они не актуальны.

Как я уже говорил, Создать продукт в определенной c подкатегории

В качестве предварительных запросов,

• Нам нужен зарегистрированный пользователь
• Нам нужна созданная категория
• Нам нужна созданная подкатегория

Во всех эти шаги, чтобы проверить тестовый сценарий ios из Создайте продукт в определенной c подкатегории , нам не нужно go через проверки входа в систему или создавать проверку категории или создавать проверки подкатегории . Нам просто нужен VALID логин, VALID категория и VALID подкатегория. Скорее всего, мы сможем сделать их доступными перед запуском теста.

так что мы будем:

Перейдя к логину с действующим логином, выберите нашу категорию и подкатегорию (или вы можете создать новые) ), а затем выполните все недействительные и допустимые сценарии тестирования, чтобы проверить Создать продукт в определенной c подкатегории . Потому что нет смысла запускать все проверки входа, когда вам нужно проверить функциональность создания продукта.

Надеюсь, это поможет, Ура

Answer 3

Взгляните на приложение Cypress Real World, созданное для демонстрации реального использования методов, шаблонов, практик и рабочих процессов Cypress.

https://www.cypress.io/blog/2020/06/11/introducing-the-cypress-real-world-app/

Answer 4

Публикация этого сообщения для всех, кто в будущем наткнется на этот вопрос и рассматривает Cypress.io для написания тестов e2e.

Это сообщение в блоге на их веб-сайте обобщает передовой опыт написания e2e

В отличном выступлении Брайана Манна показаны лучшие практики написания тестов e2e с использованием Cypress.io

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

Ответ Мудитры вполне подходит для моего вопроса, чтобы объяснить в целом, как мы должны решать сценарий ios, где тест является предпосылкой для другого теста.