Рейтинг: 5.0/5. на основе 2 оценок.
Пожалуйста, подождите...

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

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

Следующий материал будет интересен тем, кто:

  • Хочет оценить возможности использования методологии Specification by Example при автоматических проверках, а также самостоятельно описывать особенности ПО и шаги исключительно на русском языке;
  • Желает очень эффективно начать использовать Behavior Driven Design на своем проекте.

Постановка необходимой задачи

Итак, допустим, перед нами поставлена задача быстро автоматизировать проверку основного функционала веб-продукта, который создается в компании,что ориентирует свои услуги на клиентов из Восточной Европы и стран СНГ. Продукт используется на рынке очень много лет, а его документация равна несколько сотням страниц технического текста.

На постоянной основе проходят выпуски продукта, много ошибок, а опытных QA в компании не хватает (использовать независимые услуги тестирования финансово невыгодно).

Тест-менеджер одобрил использование наиболее современных инструментов автоматизированного тестирования – Specification by Example, а в будущем и всего необходимого функционала, взаимодействие с которым позволит добиться максимального покрытия кода тестами.

Записывать все придется в виде классических и понятных клиенту пользовательских историй.

Что потом? Все просто – детально расписывать тестовые сценарии в фича-документах и прикреплять их к автоматизированным проверкам!

Пошаговая спецификация

Что потребуется?

  • IDE под .Net. Наша спецификация создана для английской версии Visual Studio 2012. Во всех других IDE можно работать аналогично.
  • Подобрать и смонтировать Test Runner, если он еще не добавлен в систему. Рекомендуется использовать NUnit. Кстати, SpecFlow всецело взаимодействует и с иными приложениями для запуска проверок.

1 Этап. Установка SpecFlow

Переходим в Tools – Extensions and Updates.

Инсталляция SpecFlow

Установка SpecFlow

Следуем в Online и находим там SpecFlow.

Установка Specflow

Установка Specflow

Монтируем библиотеку. Программа «напомнит» о перезапуске Visual Studio.

2 Этап. Создание конфигурационного файла SpecFlow

Вы можете запросто пропустить этот шаг, если:

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

Необходимо заранее приготовить файл App.config с таким содержанием:

Файл App.config

Файл App.config

Вместо NUnit в данном месте можно запросто указать классический «прогонщик» тест-кейсов.

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

P.S. – Конфигурационная документация затирает стандартные настройки SpecFlow, а значит при применении на англоязычных спецификациях NUnit особо не нужен.

3 Этап. Разработка проекта

Теперь начинаем создавать тип проекта (Unit Test).

Создание типа проекта

Создание типа проекта

После этого необходимо из проекта удалить ненужный файл классического класса:

Удаление ненужного файла

Удаление ненужного файла

Теперь очередь дошла до запуска менеджера пакетов:

Менеджер пакетов

Менеджер пакетов

Внутри него создаем специальную команду:

Специальная команда

Специальная команда

В которой:

UnitTestProject1 – особое название для вашей персонализированной проверки;
SpecFlow.Nunit – специальная модификация SpecFlow под Nunit. Вы можете просто записать SpecFlow, когда проверки будут запускаться не в нем, а к примеру, SpecRun.

Консоль менеджера пакетов

Консоль менеджера пакетов

Как только система обработает запрос, внутри папки вы обнаружите документ App.config. Кстати, его не будет обнаружено внутри Solution Explorer.

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

Данную процедуру можно выполнить сразу несколькими путями:

  • Найти необходимую папку внутри системы документов и изменить ее содержимое простой заменой содержания;
  • Внести документ в project tree в ручном режиме:
    Внесение документа в дерево проекта

    Внесение документа в дерево проекта

Далее, если есть желание, можно заняться редактированием содержимого непосредственно в Visual Studio:

Редактирование содержимого в Visual Studio

Редактирование содержимого в Visual Studio

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

4 Этап. Внесение документа с обоснованием ошибки

Вносим в проект SpecFlow фича-файл:

Файл SpecFlow Feature

Файл SpecFlow Feature

Данный документ содержит специальный образец на английском языке. Так как мы настраиваем SpecFlow исключительно для русского языка, подсветка программного синтаксиса расшифрована не будет и проект технически не сможет распознать традиционные «Given/ When/Then».

Шаблон файла SpecFlow Feature

Шаблон файла SpecFlow Feature

Структуру непосредственно шаблона можно запросто изменить на свое усмотрение.

Пришло время детально описать фичу на русском языке:

Описание фичи на русском языке

Описание фичи на русском языке

К слову, при описании нужно помнить, какие именно ключевые слова и фразы ставятся исключительно с английской версией:

Ключевые слова

Ключевые слова

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

Ключевые слова на русском языке

Ключевые слова на русском языке

5 Этап. Процесс создания тестовых проверок

Внутри документа проводим запуск из системного меню специального обработчика проверочных этапов:

Обработчик проверочных этапов

Обработчик проверочных этапов

Если есть сомнения, можно повторно проверить, все ли функционирует верно и внутри созданного сценария найдены «Если», «И», «После», «Тогда».

Кнопка Generate

Кнопка Generate

Кнопка Generate проводит процесс запуска необходимых этапов генерации.

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

В итоге у вас должны сгенерироваться такие шаги со специальными «cup» для программного кода для автоматических тестов:

Шаги со специальными cup

Шаги со специальными cup

6 Этап. Запуск записанных тестов

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

Выполнить эту работу удобнее всего непосредственно с помощью контекстного меню внутри фича-документа:

Контекстное меню

Контекстное меню

Если все параметры заданы верно, а тест распознается системой как недописанный, то его старт не происходит:

Сбой старта теста

Сбой старта теста

На рисунке показаны невыполненные проверки. Nunit начинает работать со всеми проверками по новой.

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

В заключение

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

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