Разыгранная сценка как пишется

Фреймворк 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.

Тому есть три основные причины:

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

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

Что входит в набор?

Выразительные сценарии. У автоматизаторов должны быть время и желание писать хорошие, понятные сценарии (в bdd-терминологии их принято называть выразительными). В конечном счете это именно то, на чем держится весь подход.

Время на поддержку. Как и любой дополнительный инструмент, внедренный bdd-фреймворк тоже нужно поддерживать: когда мало ресурсов на поддержку проекта, либо есть большое количество легаси, bdd начинает больше мешать, чем помогать.

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

Если что-то выпадает из этого набора, велика вероятность появления антипаттернов в разработке автотестов.

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

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

Огуречные антипаттерны

Антипаттерн №1 Последовательность действий вместо бизнес-шагов

Поскольку мы автоматизируем acceptance-сценарии, нам необходимо создавать их в соответствии с идеями acceptance-тестирования. Главный консультант Atalanta Systems Ltd Стивен Нельсон-Смит в своей книге «Test-Driven Infrastructure with Chef», сформулировал отличие acceptance-тестирования от unit-тестирования так:

«Unit-тесты помогают делать вещи правильно, в то время как acceptance-тесты помогают делать правильные вещи».

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

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

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

Часто это происходит из-за желания автоматизатора переиспользовать шаги, которые уже были написаны им когда-то, и нежелания добавлять новые шаги, которые по наполнению будут похожи на уже существующие.

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

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

Одной из лучших практик, с которой я сталкивалась, для составления действительно понятных и прозрачных сценариев — это начинать составлять сценарий ДО того, как реализованы step definition, page object, и все что используется вокруг. Абстрагируйтесь от уже написанных прежде feature-файлов и существующих реализаций шагов, это позволит посмотреть на сценарии свежим взглядом и не допустить в них ошибки.

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

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

Стоит также помнить, что Then-шаги должны соответствовать идее сценария:

В этом примере Then-шаги содержат ненужные детали и акцентируют внимание на совсем другой идее — отличии формы sign in от sign up. Здесь стоит написать новый шаг, который технически вполне может быть реализован так же, но при этом сделает сценарий более прозрачным.

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

Мэтт Уинн и Аслак Хеллесой в первом издании книги «The Cucumber Book» освещали тему важности составления простых и понятных сценариев:

«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. В итоге перегруженные и тяжелые шаги наслаиваются друг на друга, что приводит к нечитаемым сценариям и сложностям в работе с ними.

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

Чтобы сделать сценарий более легким для восприятия, один из простых способов — укоротить его. Всегда проще читать сценарий, который можно целиком охватить взглядом. Здесь мы подходим к еще одной частой проблеме, связанной с вынесением шагов в Background, — это ложное внутреннее ощущение, что сценарии стали короткими (на самом деле нет).

Нужно помнить, что при чтении сценариев всегда приходится держать в голове все те шаги, которые были вынесены в Background. Есть несколько правил, которые помогут сократить объем background-секции и сделать сценарии более прозрачными:

• Если background имеет длину более 4 строк, подумайте о переносе некоторых деталей внутрь шагов, чтобы не акцентировать на них внимание в сценарии.
• Избегайте установки сложных состояний системы, если без этой информации вполне можно обойтись. Например, если тип карты и баланс счета не имеют значения, опустите это уточнение.
• Если feature-файл настолько длинный, что после скролла перестает быть видно шаги, вынесенные в Background, подумайте о разбиении feature-файла или использовании более верхнеуровневых шагов.

Антипаттерн №7 Огромные таблицы с примерами в Scenario Outline

Оutline — это классный инструмент для повышения наглядности feature-файла и более компактного его отображения. Но нужно использовать его с осторожностью, так как эта компактность часто вызывает соблазн добавить лишние проверки.

Форма примеров в outline (Examples) в виде таблицы удобна для передачи нескольких аргументов, но надо помнить, что добавление к ней еще одной строки означает добавление нового сценария, который тоже нужно поддерживать. 0н занимает время прогона и требует анализа.

Кроме того, открыв для себя outline однажды, бывает трудно остановиться, — часто хочется объединить хоть сколь-нибудь похожие сценарии в один outline, примеры (Examples) в котором уже не выглядят как небольшая табличка 2х2, а занимают чуть ли не больший объем, чем само тело сценария.

Такой outline трудно читать не только потому что в нем много примеров (Examples), но и потому, что в угоду объединения нескольких сценариев в один outline ряд шагов был настолько унифицирован, что они перестали нести пользу для понимания идеи сценария.

Здесь один большой Scenario Outline был разделен на Outline поменьше и два обычных сценария с использованием таблиц, причем первая таблица составлена таким образом, чтобы визуально соответствовать реальному меню, — это хороший прием для улучшения визуального восприятия. Кроме того, в ходе разбиения больших Outline часто получается так, что некоторые примеры (examples) оказываются избыточными и по согласованию с командой просто убираются из проверки.

Вместо заключения

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

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

Кратко

• Делайте сценарии выразительными. Это облегчает работу с ними, сокращает время на поддержку, помогает избежать недопонимания между членами команды. Не забывайте об удобных выразительных средствах Cucumber (таблицы, списки, многострочный текст). Используйте яркие имена и примеры.
• Пишите бизнес-шаги. Найдите баланс между слишком обтекаемыми и слишком подробными сценариями. Опускайте ненужные детали, описывающие конкретную реализацию шага.
• Используйте Background и Scenario Outline аккуратно. Чрезмерная увлеченность может усложнить сценарии или шаги, привести к плохой читаемости или утере основной идеи сценария.
• Уделяйте достаточно времени составлению сценариев. Например, автоматизаторам тестов можно посылать сценарии в самом начале отдельным код-ревью. Антипаттерны, которые наложились друг на друга, способны мутировать, превращаясь в страшного монстра, настолько сложного для восприятия, что так просто уже и не скажешь, какой именно антипаттерн ему мешает.

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