Почему нельзя использовать селен и огурец вместе

В этом посте я объясню, почему я считаю, что писать автоматические тесты пользовательского интерфейса с использованием Selenium и Cucumber - плохая идея.

В названии поста упоминаются Selenium и Cucumber, потому что они являются наиболее популярными инструментами автоматизации браузера и BDD соответственно, однако контекст этой статьи применим к любому инструменту автоматизации пользовательского интерфейса в сочетании с любым инструментом BDD.

Прежде чем копать глубже, давайте рассмотрим некоторую справочную информацию.




Что такое селен?

Селен - это инструмент тестирования автоматизации браузера, который способен взаимодействовать с HTML-элементами веб-приложения для имитации активности пользователя.

В Selenium WebDriver мы можем писать сценарии на нескольких языках программирования и могут быть отличным активом для тестирования нескольких ОС и кроссбраузерности.




Что такое огурец?

Огурец был создан для управления процессом разработки, основанного на поведении (BDD), чтобы заказчик мог описать свои требования в виде серии примеров, называемых сценариями, в простых текстовых файлах с использованием языка Gherkin в формате Given When Then.

В мире Cucumber эти файлы называются файлами функций, которые проверяются командой Scrum, чтобы получить четкое представление о требованиях перед началом фактической разработки.

Как только разработка начнется, разработчики и / или QA напишут определения шагов, которые по сути являются фрагментами кода, которые связывают сценарии из файлов функций с тестовым кодом, который выполняет действия с тестируемым приложением.



Селен и огурец

И селен, и огурец - отличные инструменты для своих собственных целей, но при совместном использовании все плохо сочетается! Посмотрим почему.


Истории обычно пишутся с точки зрения пользователя, например:

Характерная черта: Функциональность входа в систему

Как пользователь сайта abc.com

Я хочу, чтобы клиенты могли входить на сайт


Чтобы они могли просматривать информацию о своей учетной записи.

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

Сценарий 1: Действительный логин

Учитывая, что я нахожусь на странице входа на abc.com


Когда я ввожу действительные учетные данные

Затем меня перенаправляют на страницу «Моя учетная запись».

Таким образом, вы можете добавить больше сценариев для тестирования различных комбинаций данных.

Поскольку и история, и файл функций написаны с точки зрения высокого уровня, и поскольку мы хотим автоматизировать сценарии, кажется естественным начать писать определения шагов в Cucumber, которые вызывают Selenium для управления приложением, выполнять действия и проверьте результат.


Но вот где возникает проблема; когда мы начнем комбинировать Selenium с Cucumber для написания автоматических тестов пользовательского интерфейса.

Честно говоря, в простых случаях, таких как сценарий входа в систему выше, все хорошо сочетается друг с другом, и подход кажется правдоподобным, и на самом деле большинство примеров, которые вы видите в Интернете, демонстрируют использование Selenium и Cucumber, похоже, ограничиваются известный пример входа в систему.

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

Не дайте себя обмануть, поскольку Selenium и Cucumber могут сильно испортиться, если применить их к реальному крупному веб-приложению.

Возьмем пример страницы результатов поиска типичного приложения электронной коммерции, которое продает товары в Интернете. Обычно страница результатов поиска содержит множество функций, таких как фильтры, сортировки, список продуктов, возможность изменения поиска, возможность разбивки на страницы или автоматическая загрузка при прокрутке и т. Д., Как показано на снимке экрана ниже:

Я предполагаю, что каждая функция на странице результатов поиска добавлялась на сайт постепенно с использованием гибкой разработки.

Применяя тот же принцип, что и в нашем простом примере входа в систему, по мере разработки каждой функции у нас будет соответствующий файл функции, заполненный множеством различных сценариев. Например:

На итерации 1 разработки разрабатывается «Фильтр по цене», поэтому у нас будет файл функций для него с его собственными сценариями, связанными с ценовым фильтром.

На второй итерации разработки разрабатывается «Фильтр по звездному рейтингу», поэтому у нас будет файл функций для него с его собственными сценариями, связанными с фильтром звездного рейтинга, и так далее для каждой новой функции.

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

Как упоминалось ранее, когда приложение простое, мы можем пережить задачу автоматизации сценариев пользовательского интерфейса с помощью Selenium и Cucumber. Однако по мере роста приложения и добавления новых функций возникает сложность, поскольку между различными функциями могут быть зависимости.

Например, я мог бы сначала отфильтровать результаты поиска по цене, а затем применить другой фильтр для звездного рейтинга. А… теперь у нас проблема!

К какому файлу функций следует перейти в этот сценарий? В файле «Фильтр по рейтингу» или «Фильтр по цене»? Как насчет того, чтобы я теперь добавил сценарий для применения сортировки к моим отфильтрованным результатам для сортировки по наибольшему количеству голосов?

Если заинтересованное лицо желает увидеть, каково наше тестовое покрытие, какие файлы функций ему следует изучить? Получит ли он полную картину охвата сценария, прочитав только один из файлов функций, или ему нужно будет прочитать все файлы функций?

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

Собственно, именно этим и займутся настоящие пользователи приложения. Сначала они будут вводить свои критерии поиска, после того, как они окажутся на странице результатов поиска, они, возможно, будут разбивать на страницы, затем фильтровать, затем сортировать, затем возвращаться и так далее, и они могут выполнять эти действия в любом порядке. Не будет установленного порядка проведения мероприятий. Это реальный путь пользователя и настоящий тест системы!

Большинство ошибок в приложении обнаруживаются, когда либо сама функция содержит ошибки, либо когда две функции, которые отлично работают изолированно, не работают вместе. На этом основана модель парного тестирования.

Итак, что такого особенного в использовании селена и огурца вместе?

По возможности не следует использовать веб-интерфейс для проверки работоспособности. Функциональность функции должна быть проверена на уровне API с помощью интеграционных тестов.

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

Типичное путешествие пользователя повлечет за собой:

1 - Перейдите на домашнюю страницу сайта abc.com

2 - Найдите продукт на главной странице

3 - Просмотрите список результатов поиска.

4 - Применить фильтр и / или отсортировать

5 - Прочтите сведения о продукте

6 - Добавить товар в корзину

7 - Продолжить проверять…

Selenium отлично подходит для автоматизации этих сценариев и проверки различных элементов на каждой странице, и, как я упоминал выше, это то, на чем мы должны сосредоточиться при тестировании на уровне пользовательского интерфейса и тестировании переходов между различными состояниями.

Как можно видеть, каждое путешествие пользователя по приложению затрагивает множество страниц и потенциально взаимодействует с множеством функций на каждой и каждой странице, и мы будем проверять различные вещи на каждом этапе на протяжении всего пути, поэтому с помощью файл функций документировать эти сценарии совершенно бессмысленно, потому что мы не тестируем функцию, мы тестируем интегрированную систему.

Когда мы пытаемся написать сквозные сценарии в формате «дано-когда-тогда», все идет по-настоящему плохо. Сколько Гивенов у нас будет? Сколько у нас будет тэнов?

Можно утверждать, что для сквозных тестов мы могли бы просто использовать Selenium отдельно без Cucumber и иметь отдельные автоматические тесты для каждой функции с использованием Selenium и Cucumber. Опять же, я не рекомендую этот подход, поскольку у вас могут быть повторяющиеся тесты, а мы знаем, насколько медленными и нестабильными являются тесты пользовательского интерфейса, поэтому мы должны стремиться к тому, чтобы их было меньше, а не больше! Более того, вам все равно придется иметь дело с тестами зависимостей функций.

Резюме

Cucumber - отличный инструмент для проверки поведения функции на уровне API с помощью интеграционных тестов, где каждая функция может быть тщательно протестирована. Этот инструмент следует использовать для тестирования историй.

Selenium - отличный инструмент для автоматизации пользовательских сценариев на уровне пользовательского интерфейса и проверки поведения системы в целом, охватывающей множество пользовательских историй.

Когда мы переходим к тестированию системной интеграции или тестированию пользовательского интерфейса, лучше всего использовать Selenium без базовой инфраструктуры Cucumber, поскольку попытка написать файлы функций Cucumber для пользовательских поездок может оказаться очень громоздкой и не будет служить цели, для которой создан инструмент.

Моя статья основана на выводе фактов!

  • Если есть какая-то ценность в использовании огурца, то это на уровне функции.
  • Проверять функциональность функции лучше всего за пределами пользовательского интерфейса, например API-тесты.
  • Даже на тестах уровня API огурец терпит неудачу.
  • Тесты пользовательского интерфейса должны охватывать пользовательские / бизнес-сценарии, а не отдельные функции.

Cucumber прекрасно работает с упрощенным и наивным представлением тестов и сценариев, таких как любимая всеми функция входа в систему.

Учитывая, что я нахожусь на странице входа в систему
Когда я ввожу действительные учетные данные
Тогда я должен увидеть свою учетную запись

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

Это только для входа в систему; попробуйте написать сквозной тест на огурце!

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

За один путь пользователя по приложению происходит очень много всего.

Огурец определенно НЕ подходит для тестирования пользовательских / бизнес-сценариев.