Разработка, управляемая поведением - SpecFlow

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

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

Особые элементы и SpecFlow

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

  • Элемент Feature предоставляет заголовок для файла объектов. Элемент функции включает в себя имя и общее описание соответствующей функции в вашем приложении.

    • SpecFlow генерирует класс модульного теста для элемента объекта с именем класса, полученным из имени объекта.

    • SpecFlow генерирует исполняемые модульные тесты из сценариев, которые представляют критерии приемлемости.

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

    • Сценарии имеют имя и могут состоять из нескольких этапов сценария.

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

Несколько этапов сценария

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

  • Различные типы шагов начинаются с ключевых слов « Given», «When» или « Then», соответственно, и последующие шаги того же типа могут быть связаны с помощью ключевых слов « And» и « But» .

  • Синтаксис Gherkin допускает любую комбинацию этих трех типов шагов, но сценарий обычно имеет отдельные блоки операторов Given, When и Then .

  • Шаги сценария определяются с использованием текста и могут иметь дополнительную таблицу с именем DataTable или многострочный текст, называемый аргументами DocString.

  • Шаги сценария являются основным способом выполнения любого пользовательского кода для автоматизации приложения.

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

  • Соответствие выполняется во время выполнения, поэтому сгенерированные тесты могут быть скомпилированы и выполнены, даже если привязка еще не реализована.

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

Теги

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

  • Если поддерживается модульным тестом, SpecFlow генерирует категории из тегов.

  • Сгенерированное имя категории совпадает с именем тега, но без начального @.

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

Фоновые элементы

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

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

  • SpecFlow генерирует метод из фоновых элементов, который вызывается из всех модульных тестов, созданных для сценариев.

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

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

  • Если инфраструктура модульного тестирования поддерживает это, SpecFlow генерирует тесты на основе строк из контуров сценария.

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

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

  • Поэтому хорошей практикой является выбор уникального и описательного параметра в качестве первого столбца в наборе примеров.

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

  • SpecFlow выполняет замену заполнителя как отдельную фазу перед сопоставлением привязок шага.

  • Таким образом, реализация и параметры в привязках шагов не зависят от того, выполняются ли они посредством прямого сценария или схемы сценария.

  • Это позволяет позже указать дополнительные примеры в приемочных тестах без изменения привязок шага.

Комментарии

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