Разработка на основе поведения - SpecFlow

SpecFlow - проект с открытым исходным кодом. Исходный код размещен на GitHub. Файлы функций, используемые SpecFlow для хранения критерия приемлемости функций (вариантов использования, пользовательских историй) в вашем приложении, определяются с использованием синтаксиса Gherkin.

Формат Gherkin был введен Cucumber и также используется другими инструментами. Язык Gherkin поддерживается как проект на GitHub -https://github.com/cucumber/gherkin

Элементы функций и SpecFlow

Ключевые особенности элементов Feature:

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

Несколько шагов сценария

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

Различные типы шагов начинаются с Given, When или Then ключевые слова соответственно, и последующие шаги того же типа могут быть связаны с помощью And а также But ключевые слова.
Синтаксис Gherkin допускает любую комбинацию этих трех типов шагов, но сценарий обычно имеет отдельные блоки Given, When а также Then заявления.
Шаги сценария определяются с помощью текста и могут иметь дополнительную таблицу с именем DataTable или многострочный текст с именем DocString arguments.
Шаги сценария - это основной способ выполнения любого настраиваемого кода для автоматизации приложения.
SpecFlow генерирует вызов внутри метода модульного тестирования для каждого шага сценария. Вызов выполняется средой выполнения SpecFlow, которая выполнит определение шага, соответствующее шагу сценария.
Сопоставление выполняется во время выполнения, поэтому сгенерированные тесты могут быть скомпилированы и выполнены, даже если привязка еще не реализована.
Вы можете включать таблицы и многострочные аргументы в шаги сценария. Они используются в определениях шагов и передаются в виде дополнительных табличных или строковых аргументов.

Теги - это маркеры, которые можно назначать функциям и сценариям. Назначение тега функции эквивалентно назначению тега всем сценариям в файле функции. Имя тега с начальным символом @ обозначает тег.

Если это поддерживается платформой модульного тестирования, SpecFlow генерирует категории из тегов.
Сгенерированное имя категории совпадает с именем тега, но без символа @ в начале.
Вы можете фильтровать и группировать тесты, которые нужно выполнить, с помощью этих категорий модульных тестов. Например, вы можете пометить важные тесты с помощью @important, а затем выполнять эти тесты чаще.

Элементы фона

Элемент фонового языка позволяет указать общее предварительное условие для всех сценариев в файле функций.

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

Контуры сценария

Схемы сценария могут использоваться для определения приемочных испытаний на основе данных. Схема сценария всегда состоит из спецификации шаблона сценария (сценарий с заполнителями данных с использованием синтаксиса <placeholder>) и набора примеров, которые предоставляют значения для заполнителей.

Если платформа модульного тестирования поддерживает это, SpecFlow генерирует тесты на основе строк из схем сценария.
В противном случае он генерирует параметризованный логический метод модульного тестирования для схемы сценария и индивидуальный метод модульного тестирования для каждого набора примеров.
Для лучшей прослеживаемости сгенерированные имена методов модульного тестирования берутся из заголовка схемы сценария и первого значения примеров (первый столбец таблицы примеров).
Поэтому рекомендуется выбирать уникальный и описательный параметр в качестве первого столбца в наборе примеров.
Поскольку синтаксис Gherkin требует, чтобы все столбцы примеров имели соответствующие заполнители в схеме сценария, вы даже можете ввести произвольный столбец в наборы примеров, используемые для именования тестов с большей удобочитаемостью.
SpecFlow выполняет замену заполнителя как отдельный этап перед сопоставлением привязок шага.
Таким образом, реализация и параметры в привязках шагов не зависят от того, выполняются ли они посредством прямого сценария или схемы сценария.
Это позволяет вам позже указать дополнительные примеры в приемочных тестах без изменения привязки шагов.

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