Cucumber программа что это

,

Передача коллекций в аргументы

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

Для замены разделителя, можно воспользоваться аннотацией Delimiter:

DataTable – это класс, который эмулирует табличное представление данных. Для доступа к данным в нем имеется большое количество методов. Рассмотрим некоторые из них:

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

Данный пример выведет на консоль:

Файл
Редактировать
О программе

Метод преобразует таблицу в список списков:

На консоль будет выведено:

Файл true 5
Редактировать false 8

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

Метод выведет на консоль:

Редактировать false 8
О программе true 2

Создадим для примера класс Menu:

Для первого способа шаг в сценарии запишем в следующем виде:

Файл true 5
Редактировать false 8
О программе true 2

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

Для второго способа приведем шаг сценария к следующему виду:

А в аргументе описания шага используем аннотацию @Transpose.

Cucumber, как и в предыдущем примере, создаст связанный список объектов, но, в данном случае, наименования полей записывается в первой колонке таблицы.

Для передачи многострочных данных в аргумент метода, их необходимо экранировать тремя двойными кавычками:

Данные в метод приходят в виде объекта класса String:

Фреймворк самостоятельно приводит данные из сценария к типу данных, указанному в аргументе метода. Если это невозможно, то выбрасывает исключение ConversionException. Это справедливо и для классов Date и Calendar. Рассмотрим пример:

Все прекрасно сработало, Cucumber преобразовал 04.05.2017 в объект класса Date со значением «Thu May 04 00:00:00 EET 2017».

Рассмотрим еще один пример:

Дойдя до этого шага, Cucumber выбросил исключение:

Почему первый пример сработал, а второй нет?

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

Структура сценария

Бывают случаи, когда необходимо запустить тест несколько раз с различным набором данных, в таких случая на помощь приходит конструкция «Структура сценария»:

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

Использование хуков

Cucumber поддерживает хуки (hooks) – методы, запускаемые до или после сценария. Для их обозначения используется аннотация Before и After. Класс с хуками должен находиться в пакете, указанном в опциях фреймворка. Пример класса с хуками:

Метод c аннотацией Before будет запускаться перед каждым сценарием, After – после.

Порядок выполнения

Хукам можно задать порядок, в котором они будут выполняться. Для этого необходимо в аннотации указать параметр order. По умолчанию значение order равно 10000.

Для Before чем меньше это значение, тем раньше выполнится метод:

В данном примере первым выполнится метод connectToServer(), затем prepareData().

After отрабатывает в обратном порядке.

Тэгирование

означает «за исключением». Пример:

Метод connectToServer будет выполнен для всех сценариев с тэгом correct, метод prepareData для всех сценариев за исключением сценариев с тэгом fail.

Scenario class

Если в определении метода-хука в аргументе указать объект класса Scenario, то в данном методе можно будет узнать много полезной информации о запущенном сценарии, например:

аутентификация-банковской-карты;успешная-аутентификация
Успешная аутентификация
passed
false
[@correct, @all]

Источник

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.

Источник

• ← Cube что это за программа
• cumulative update for windows 10 version next что это →