среда, 11 ноября 2015 г.

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. … (предлагайте свои улучшения)

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

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

Отправить комментарий

Условия копирования публикаций:

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