BDD & BDT сценарии: куда расширяться вширь или вглубь?

Если вы работаете с BDD или BDT, то наверняка сталкивались с написанием историй на языке типа Геркин (в JBehave – это *.story, в specflow – это *.feature). Проблем писать эти самые истории/фичи нет, если не надо делать проверки больших наборов данных.

Есть механизмы работы с ними, но тут есть варианты, как именно их использовать:

• Данные могут быть жестко вшиты в код шага или в БД (или еще куда-то...):

  Scenario: Creating a test object
  Given I am on the test page
  When I create the default object

• Данные можно передавать прямо в шаги как параметры:

  Scenario: Creating a test object
  Given I am on the test page
  When I create test object with name “TestObject” and type “Normal” 

• Данные можно передавать прямо в шаги таблицей:

Scenario: Creating a test object
Given I am on the test page
When I create test object 
|name|type|
| TestObject | Normal |

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

Scenario: Creating a test object
Given I am on the test page
When I create test object with name “<name>” and type “<type>”
Examples:
| name | type |
| TestObject1 | Normal |
| TestObject2 | Normal |

Вот тут и начинается все интересное - Как лучше задизайнить сценарий?

Если данных много, то получаем либо кучу параметров в шагах, либо большие таблицы. Понятно, что уйти от этой проблемы сложно, но, в принципе, возможно. Нужно только пользоваться правилом «use common sense»:

1. Файл истории / фичи должен быть читабельным, т.е. вся необходимая информация должна умещаться на экран желательно без горизонтального скроллинга (вертикальный допускается, т.к. обычно в начале файла идет куча разной мета информации).
2. Используйте простые имена параметров в CamelCase (пробелы и подчеркивания лишь удлиняют названия)
3. Если у вас появляется очень «широкий» шаг с большим количеством параметров, то это повод задуматься над разбиением его на несколько или же над использованием таблицы
4. Если у вас появляется очень широкая таблица, то это повод задуматься над реорганизацией шагов
5. Использование таблиц должно быть хорошо продумано, т.к. дополнительный код в реализации шагов.
6. Имплементация шагов не должна содержать большого количества запутанной логики, зависящей от значений параметров (каждый дополнительный блок if или switch – это сигнал о возможной необходимости использования нового шага)
7. Не пытайтесь уместить все проверки в 1 сценарий (лучше иметь несколько простых читабельных сценариев, чем 1 но запутанный)
8. … (предлагайте свои улучшения)

«Гибкость - сестра таланта» (с) Алексей Булат.

Будьте гибкими, не останавливайтесь на достигнутом, ищите пути к упрощению ваших историй.