что такое cucumber framework
Заметки программистера
Страницы
Java со вкусом огурчика
Cucumber
Основой описания сценария тестирования являются шаги, такие как Given, When, Then. Каждому шагу соответствует аннотация, которая с помощью регулярного выражения связывает метод, над которым объявлена, со строкой в текстовом описании сценария.
Шаги тестирования группируются в сценарии (Scenario), которые в свою очередь описывают некоторую функциональность (Feature).
Структура проекта
Интеграция с популярными библиотеками тестирования
Интеграция с JUnit
Интеграция с TestNG
Способы описать параметры
Этот фреймворк предоставляет несколько механизмов описания параметров тестов прямо в текстовом файле.
Обратите внимание на описание сценария, при реализации данного подхода. Вместо ключевого слова Scenario здесь используется Scenario Outline.
На этом функциональность библиотеки не заканчивается и Cucumber предлагает описывать в качестве аргументов целые классы!
Предустановки
Не всем огурцы по нраву.
если вы стремитесь к тому, чтобы вашим фреймворком могли пользоваться даже дебилы, именно они им и будут пользоваться.
Если подходить к пользованию Cucumber с умом и к месту, можно поиметь не мало счастья.
Предложенный автором статьи «Введение в BDD» подход к написанию тестов выглядит действительно многообещающим. Но на практике имена из серии shouldDoSomething очень трудно воспринимаются при чтении кода и требуют достаточно много усилий для того, чтобы понять, какой именно смысл вложен в их название. Немногим лучше обстоят дела в Scala с фреймворком specs2. Но код тестов все еще остается трудно читаемый.
Пример теста на spec2
Замечу, что если речь идет о модульных тестах, которые по своему определению просты и компактны, то использование Cucumber скорее всего будет лишним. Но в случае больших и подчас запутанных функциональных тестов, очень важно, чтобы их сценарии были описаны в простом и строго структурированном виде. И именно здесь Cucumber может проявить себя с лучшей стороны!
UI тесты: Cucumber + Selenide
Сегодня поговорим о создании UI smoke-теста для сайта с использованием фреймворков Cucumber и Selenide. Статья рассчитана на junior, который совсем ничего не знает про данные фреймворки. Опытный junior найдет во второй части интересные моменты, до которых я доходил пару месяцев.
Статья состоит из двух частей:
Фреймворки
Selenide – фреймворк (а точнее библиотека), обертывающий Selenium. Чем он отличается, прекрасно описано автором, Андреем Солнцевым. Главное отличие – Selenide позволяет сократить кучу строчек кода при написании UI тестов, что является одной из главных задач при создании тестов/написании кода, ибо Вы должны заботиться о том тестере, который придет после Вас и должен будет разбирать Ваше творение.
Cucumber – это фреймворк, реализующий подход BDD/TDD.
Я не претендую на глубокое теоретическое знание BDD/TDD, пока что для меня они суть одно и тоже.
BDD/TDD с практической точки зрения:
Прежде чем программисты начнут писать код (как это делается в большинстве случаев), и тестеры и программисты садятся за круглый стол и обсуждают – как именно фича будет работать. Результатом круглого стола является записанная на бумаге фича – набор действий клиента/пользователя, который приводит к некому результату: а) нажал сюда; б) ввел цифры туда; в) получил результат там
В результате такого круглого стола создается одно понимание на всех данной фичи, задокументированное на бумаге
Еще плюсы Cucumber:
Разберем первую, простую часть simple_selenide_cucumber.
Структура проекта:
Используем Intellij IDEA, Maven и Junit.
В mail.txt записаны логины, пароли аккаунтов для работы с тестом. ВНИМАНИЕ: если будете запускать у себя, имейте ввиду, что система выкинет одного из юзеров, которые будут логиниться под одним логином/паролем. Поменяйте мейл
В pom.xml прописываем следующие dependency:
Файл smoketest#1.feature является той самой фичей (описанием фичи), которую согласовали программисты и тестеры за круглым столом (в идеальном мире:). Как видим, это описание действий пользователя на сайте, записанные в человеко-понятной форме, т.е. это еще и ваш файл логирования при условии, что каждый степ(действие) не подразумевает очень сложной логики:
Создание вашего UI теста начинается именно с этого файла, файл с расширением .feature. Вы должны поместить его в пакет test/java/…/features/
Фича должна начинаться с ключевого слова:
Здесь указывается общими словами что именно делает фича. В нашем случае smoke-теста это «Пройти через сервис до страницы Яндекс.платежей»
Далее идет ключевое слово:
Сценарий фактически является отдельным тестом, т.е. фича может содержать сколько угодно сценариев (тестов). Все сценарии, очевидно, должны относиться к данной фиче. В нашем случае будет два сценария, первый – пройти до кнопки «Купить» и второй – пройти до страницы платежей. По правилам тестирования, сценарии (тесты) должны быть независимыми, т.е. успех прохождения одного сценария не должен зависеть от успеха прохождения второго сценария. ВНИМАНИЕ: в нашем случае это не выполняется – второй сценарий начинается на месте остановки первого сценария, и если первый свалится, то второй тоже.
У сценария также есть краткое описание – что именно он делает.
Given — обозначает начальные условия, «Дано: то-то и то-то»
When – действия пользователя: нажать сюда, подождать то
Then – результат, который получается: чаще всего это некая проверка, как в нашем случае
Старайтесь соблюдать разделение степов на указанные три части ( Given, When, Then ), т.к. это правила BDD/TDD.
Вы также можете использовать лямбда-выражения для описания степов. Но я не буду разбирать это здесь, т.к. это отдельная тема. Будем делать по старинке.
Разберем определение степа подробнее:
Regex – это тема отдельной статьи, почитайте где-нибудь, материала полно.
Приведу ключевые используемые символы regex, которые нужны для старта:
Разберем некоторые степы.
В описании логики степов используется Selenide
Вид в фиче: Given open riskmarket.ru
Благодаря методу open(…) от Selenide в одной строчке создается instance WebDriver (по умолчанию Firefox) и происходит переход на указанный url. Закрывать/убивать instance не нужно, это сделает Selenide
Перед вами пример переиспользования степа. Старайтесь переиспользовать степы как можно чаще, не плодите код. В нашем примере в аргументе аннотации указываем, что «кнопка может содержать какой угодно текст, но в кавычках». Что прикольно, можно использовать любой язык.
Вообще говоря, для описания степов также можно использовать любой язык – можно писать так:
Раз название кнопки – это аргумент, то указываем его в сигнатуре метода:
Condition – это класс Selenide, в котором описаны много разных условий, посмотрите, пригодится.
И в конце, когда мы дождались появления элемента, кликаем по нему.
К слову, то, что здесь описано в одну строку, в чистом Selenium у вас бы заняло несколько строчек кода, с созданием WebDriverWait.
sendKeys(String) — отрпавляет текст в элемент.
При описании степов как параметр можно принимать списки – элементы перечисляются через запятую.
Остальные степы похожи на описанные выше.
В pom.xml в этот проект был добавлен Junit только из-за последнего степа, где проверка, что открылся нужный url, происходит с помощью assertThat().
CucumberTalks: избегаем антипаттернов и пишем выразительные сценарии
Фреймворк Cucumber используют как часть bdd-подхода к разработке, так и как отдельный инструмент для автотестов. 40+ млн скачиваний обеспечили фреймворку богатый опыт использования, но актуализировали поверхностное отношение к этому инструменту. Разбираем популярные огуречные антипаттерны и учимся писать действительно выразительные сценарии.
Я Женя Шереметова, работаю в группе автоматизированного тестирования МойОфис. В своей работе мы используем инструмент Cucumber. За семь лет существования компании накопилось много легаси в тестах, в какой-то момент был сделан акцент на увеличении покрытия и на скорости написания тестов. Необходимость рефакторинга назрела уже давно, и первыми звоночками стали увеличение времени поддержки тестов и неудобство прохождения код-ревью сценариев.
C фреймворком Cucumber я работаю около пяти лет, и за все время работы с этим инструментом как в МойОфис, так и на других проектах, у меня накопился опыт, которым я хочу поделиться с сообществом.
Как и вам, мне приходится много читать про «огуречные практики» на Stackoverflow и других форумах. И я наблюдаю, что зачастую инструмент используют не по назначению, либо не используют все его преимущества.
Происходит это из-за того, что автоматизаторы рассматривают Cucumber просто как обертку над кодом для красоты, упуская при этом идею самой концепции bdd (Behavior-driven development), лежащей в основе Cucumber. Такой подход приводит к тому, что фичи инструмента используются неправильно, и сам инструмент вносит хаос туда, где он должен улучшать прозрачность.
В этом тексте я хочу сделать акцент на том, как писать выразительные сценарии на Cucumber, зачем они нужны, и рассказать об основных антипаттернах, которые мешают достигать нужных результатов — делать процесс разработки понятным и прозрачным для всех участников, как и задумывалось создателем bdd-подхода Деном Нортом.
Напомню, что bdd-подход объединил в себе лучшие практики TDD (Test Driven Development), где разработка кода происходит через тесты, написанные самими разработчиками, и позволил сократить разрыв между техническими и нетехническими (бизнес) членами команды.
Зачем нужен Cucumber в разработке
Cucumber является наиболее популярным на сегодняшний день кроссплатформенным bdd-фреймворком, который используют в автотестах, даже если фактически в команде самого bdd-подхода к разработке нет. Это вовсе не плохо, ведь у Cucumber есть много преимуществ даже в отрыве от общего bdd-подхода. Чтобы разобраться в них, ответим на вопрос, зачем внедряют в процесс разработки bdd-фреймворки типа Cucumber.
Тому есть три основные причины:
Что входит в набор?
Выразительные сценарии. У автоматизаторов должны быть время и желание писать хорошие, понятные сценарии (в bdd-терминологии их принято называть выразительными). В конечном счете это именно то, на чем держится весь подход.
Время на поддержку. Как и любой дополнительный инструмент, внедренный bdd-фреймворк тоже нужно поддерживать: когда мало ресурсов на поддержку проекта, либо есть большое количество легаси, bdd начинает больше мешать, чем помогать.
Командная вовлеченность. Здорово, если не только тестировщики несут ответственность за качество. Cucumber особенно полезен, когда люди из бизнеса, аналитики и разработчики вносят свой вклад и сотрудничают в составлении и поддержке тестовых сценариев. Участие в написании сценариев и их чтение помогает людям лучше осознать свою собственную ответственность за результат.
Если что-то выпадает из этого набора, велика вероятность появления антипаттернов в разработке автотестов.
В данной статье я буду апеллировать к понятию антипаттернов как наиболее распространенных ошибок, возникающих в процессе применении инструмента, которые зачастую приводят к тому, что с ним становится неудобно работать, нельзя использовать все его преимущества и сложно его поддерживать.
Избегайте антипаттернов, работайте над ошибками. Так вы сможете сделать ваши тесты простыми и понятными, их будет легко поддерживать, и, как следствие, они принесут максимум пользы.
Огуречные антипаттерны
Антипаттерн №1 Последовательность действий вместо бизнес-шагов
«Unit-тесты помогают делать вещи правильно, в то время как acceptance-тесты помогают делать правильные вещи».
При создании каждого нового сценария нужно помнить, что в конечном итоге он должен быть ориентирован на бизнес-требования и описывать ценность для пользователя.
Часто несоблюдение этой простой идеи — идеи составления бизнес-сценариев — приводит к тому, что Cucumber-сценарии превращаются в последовательность действий, которая отражает скорее конкретную реализацию, а не бизнес-идею. Из-за этого сценарии становятся однообразными, теряется их выразительность, а главная задача bdd-фреймворка — сделать сценарии понятными каждому участнику процесса — становится невыполнимой.
В этом сценарии каждый шаг представляет собой отдельное действие. Такой подход нагружает сценарий лишними деталями, которые не имеют отношения к его сути. Приходится не только держать в голове всю последовательность действий, но и отвлекаться на ненужные детали вроде названий кнопок, экранов, списков.
Часто это происходит из-за желания автоматизатора переиспользовать шаги, которые уже были написаны им когда-то, и нежелания добавлять новые шаги, которые по наполнению будут похожи на уже существующие.
Помните, что шаги в Cucumber могут быть переиспользованы, но это не самоцель. Намного важнее написать сценарий так, чтобы он был выразительным, не был перегружен лишней информацией и отражал ценность для пользователя. А проблема повторяющихся шагов должна решаться на уровне ниже — в step definitions.
Как правило, последовательность действий вместо бизнес-шагов появляется в сценариях из-за того, что автоматизаторы при составлении сценариев отталкиваются «от реализации», начиная сразу продумывать, как это будет покрыто кодом. Это приводит не только к отсутствию выразительности, но и к тому, что в сценарий заезжают и другие антипаттерны.
Одной из лучших практик, с которой я сталкивалась, для составления действительно понятных и прозрачных сценариев — это начинать составлять сценарий ДО того, как реализованы step definition, page object, и все что используется вокруг. Абстрагируйтесь от уже написанных прежде feature-файлов и существующих реализаций шагов, это позволит посмотреть на сценарии свежим взглядом и не допустить в них ошибки.
Однако в некоторых случаях использование в качестве шагов последовательности действий оправдано. Например, когда нужно проверить, что действие выполняется именно так, а не иначе.
Такой сценарий имеет свою специфику: здесь проверяется конкретный способ выполнить действие, и на это есть явное указание как в названии сценария, так и в шагах.
Стоит также помнить, что Then-шаги должны соответствовать идее сценария:
В этом примере Then-шаги содержат ненужные детали и акцентируют внимание на совсем другой идее — отличии формы sign in от sign up. Здесь стоит написать новый шаг, который технически вполне может быть реализован так же, но при этом сделает сценарий более прозрачным.
Не бойтесь создавать новые, более подходящие шаги для конкретного сценария вместо переиспользования уже существующих. Это поможет сократить время на поддержку вашей живой документации в дальнейшем, увеличит прозрачность сценариев, позволит избежать недопонимания между членами команды.
Антипаттерн №2 Сценарии без четких формулировок, говорящих названий, показательных примеров
«Cucumber был разработан, чтобы помочь навести мосты между техническими и нетехническими специалистами команды разработки. Постарайтесь написать acceptance-тесты таким образом, чтобы они были понятны любому члену команды».
Это означает, что все сценарии должны быть настолько выразительными, насколько это возможно, чтобы все заинтересованные стороны с разной степенью вовлеченности (разработчики, менеджеры, аналитики) понимали, что происходит.
Чем четче будут формулировки, тем меньше возникнет недопонимания со всех сторон. Чтобы добиться этого, следует достаточно времени уделять качеству составляемых сценариев, независимо от причин, которые изначально привели вас к bdd-фреймворку, будь то отладка общения со стейкхолдерами или желание упростить документацию кода.
Среди ошибок, которые приводят к потере выразительности и качества сценариев, встречаются отсутствие ярких имен, говорящих названий, показательных примеров. Читателю намного сложнее воспринимать скучные имена вроде User 1, User 2, Chat A, Site B.
Читать обезличенный сценарий объективно сложнее. К тому же, из-за отсутствия ярких имен в сценарии зачастую появляется ненужная информация, которая еще больше его захламляет (вроде Account 1 и Account 2). Добавление контекста помогает читателю быстрее уловить идею сценария и вникнуть в его суть. Такие сценарии воспринимаются легче, их проще анализировать, кроме того, читать яркие, продуманные сценарии просто приятнее.
Хорошо продуманные тестовые данные тоже часто помогают добавить выразительности сценарию. Например, используя показательные примеры, можно избежать дополнительных описаний сценария, тем самым делая его проще. Это особенно важно, когда проверка сложная. В этом случае выразительность сценария, достаточная, чтобы описать самого себя, сильно облегчает код-ревью и последующую поддержку.
В этом сценарии довольно трудно понять, по какому принципу определяется валидность пароля, а при усложнении условий придется вводить еще большее количество примеров, в которых легко запутаться уже на этапе создания, и еще труднее будет их поддерживать. Вводить массивные описания (descriptions) тоже не панацея, поскольку может еще сильнее усложнить чтение и понимание сценария. Поэтому нужно всегда стараться вынести максимум из выразительных средств языка, хорошо продумывать сценарий, грамотно составлять примеры.
Антипаттерн №3 Бедные сценарии без использования выразительных средств Cucumber
В Cucumber существует ряд выразительных средств, которые часто используются как способы передачи данных внутрь шага. Например, списки (List), таблицы (Data Tables), многострочный текст (Doc Strings).
Иногда бывает полезно использовать выразительные средства не для передачи параметров в шаги, а для наглядного преставления данных — чтобы облегчить понимание сценария.
Вся работа с таблицей, которая происходит в первом сценарии, может быть представлена в виде data table. «А что если я не хочу реализовывать заполнение таблицы данными из Given, что если я хочу открыть предзаполненный файл, как это делалось в Given file «sorting.xods» is opened?», спросите вы.
Действительно, передаваемую в step definition таблицу из Given совсем не обязательно будет потом использовать для реализации кода. На уровне step definition вполне может быть реализовано и открытие предзаполненного файла (как это делалось в Given file «sorting.xods»is opened).
Однако в feature-файле для большей прозрачности можно применять таблицу как средство выразительности, — в явном виде показать ее фрагмент, который имеет значение для проверки. Такой вариант написания шага делает сценарий нагляднее, согласны?
Антипаттерн №4 Путаница в ключевых словах Given, When, Then
Шаги в Cucumber устроены так, что для любого реализованного шага можно использовать любое ключевое слово, независимо от того, как этот шаг был инициирован в step definitions.
Пользователи Cucumber часто не придают этому значения и используют ключевые слова как придется, тем самым ухудшая читаемость и прозрачность сценария.
Следует помнить, что шаги Given, When, Then должны отличаться друг от друга не только синтаксически, но и по смыслу, который в них вкладывается.
Given-шаги выражают контекст, предусловия — это все то, что уже произошло в прошлом:
Given the app is installed
When-шаги — это действие, которое изменяет состояние системы в соответствии с идеей сценария — настоящее время:
When I login to my account
Then-шаги — это ожидаемый результат — ближайшее будущее:
Then I should see my personal profile
Необходимо четко различать Given-, When- и Then-шаги. Путаница в предусловиях (Given) и действиях (When) часто приводит к потере понимания того, что именно проверяется в сценарии. А размытие границ между действиями (When) и ожидаемыми результатами (Then) ведет к последующим ошибкам в реализации этих шагов. Выразительность сценария при этом тоже страдает.
При составлении сценария старайтесь рассказать историю, — правильное использование ключевых слов Given, When, Then поможет в этом. Также не забывайте использовать And и But для улучшения читаемости и благозвучности сценария.
Также стоит обращать внимание на порядок шагов: группы шагов Given, When и Then должны следовать друг за другом, смешивать их нежелательно. Старайтесь не допускать ситуации, когда после группы Then-шагов снова используются When-, а после них опять Then-.
Антипаттерн №5 Добавление ненужных шагов в погоне за выделением Background
В ситуации, когда есть несколько сценариев с одинаковыми шагами, их можно объединить в Background.
Важно помнить, что background должен содержать только Given шаги, поэтому в Background-секции избегайте использования настоящего или будущего времени и написания шагов от первого лица (например, используйте «Given the link is opened» вместо «Given I open the link»).
Стоит обратить внимание, что выделять шаги в background необходимо уже после того, как сценарии для данного feature-файла написаны, так как обратное зачастую приводит к появлению ненужных шагов, бессмысленных для следующих сценариев.
Пока шагов мало, держать их в голове относительно несложно. Но когда их становится больше, сложность восприятия существенно возрастает. Приходится постоянно думать о том, почему сценарий составлен так, а не иначе, зачем здесь лишние шаги и какую функцию (в плохом случае единственная функция — это вынесение общей части в background) они выполняют.
В приведенном примере второй сценарий не нуждается в отдельно стоящих шагах, описывающих процесс регистрации. Если в первом сценарии необходимо было явно указать, что логин является действием, изменяющим состояние системы для получения ожидаемого результата, то во втором случае скорее стоит объединить это в один общий Given-шаг.
В таком случае будет четко виден акцент на идее сценария и сути проверки — возвращении на экран логина после выхода из системы. Кроме того, теперь очевидно, что стоит подумать о вынесении этого сценария в отдельный feature-файл, поскольку к проверке логина он отношения не имеет.
Часто важность такого акцентирования ускользает из-за желания выделить максимальное количество шагов в background. В итоге перегруженные и тяжелые шаги наслаиваются друг на друга, что приводит к нечитаемым сценариям и сложностям в работе с ними.
Старайтесь не усложнять сценарии и не пренебрегать понятностью в погоне за более универсальными конструкциями и вынесением максимального количества шагов в бэкграунд.
Антипаттерн №6 Огромный Background
Чтобы сделать сценарий более легким для восприятия, один из простых способов — укоротить его. Всегда проще читать сценарий, который можно целиком охватить взглядом. Здесь мы подходим к еще одной частой проблеме, связанной с вынесением шагов в Background, — это ложное внутреннее ощущение, что сценарии стали короткими (на самом деле нет).
Нужно помнить, что при чтении сценариев всегда приходится держать в голове все те шаги, которые были вынесены в Background. Есть несколько правил, которые помогут сократить объем background-секции и сделать сценарии более прозрачными:
Антипаттерн №7 Огромные таблицы с примерами в Scenario Outline
Оutline — это классный инструмент для повышения наглядности feature-файла и более компактного его отображения. Но нужно использовать его с осторожностью, так как эта компактность часто вызывает соблазн добавить лишние проверки.
Форма примеров в outline (Examples) в виде таблицы удобна для передачи нескольких аргументов, но надо помнить, что добавление к ней еще одной строки означает добавление нового сценария, который тоже нужно поддерживать. 0н занимает время прогона и требует анализа.
Кроме того, открыв для себя outline однажды, бывает трудно остановиться, — часто хочется объединить хоть сколь-нибудь похожие сценарии в один outline, примеры (Examples) в котором уже не выглядят как небольшая табличка 2х2, а занимают чуть ли не больший объем, чем само тело сценария.
Такой outline трудно читать не только потому что в нем много примеров (Examples), но и потому, что в угоду объединения нескольких сценариев в один outline ряд шагов был настолько унифицирован, что они перестали нести пользу для понимания идеи сценария.
Здесь один большой Scenario Outline был разделен на Outline поменьше и два обычных сценария с использованием таблиц, причем первая таблица составлена таким образом, чтобы визуально соответствовать реальному меню, — это хороший прием для улучшения визуального восприятия. Кроме того, в ходе разбиения больших Outline часто получается так, что некоторые примеры (examples) оказываются избыточными и по согласованию с командой просто убираются из проверки.
Вместо заключения
Тема антипаттернов в Cucumber бесконечна, но нужно уметь остановиться, — не только в тексте, но и в погоне за перфекционизмом. В этой статье я рассмотрела ситуации, с которыми чаще всего сталкиваюсь на практике, и которые наиболее болезненно отражаются на последующих поддержке/использовании/изменении сценариев.
В своей работе я стараюсь максимально избегать описанных выше ситуаций, но всегда помню, что у любых паттернов (и антипаттернов) есть исключения. Поймать баланс между «как по учебнику» и «как нравится» важнее, чем бездумное следование правилам.
Кратко
Работа с такими сценариями и их поддержка превращается в ночной кошмар автоматизатора, поэтому стоит внимательно отнестись к продумыванию состава feature-файла, сценариев и шагов, четкости формулировок, выбору инструментов и выразительных средств Cucumber.