В сети практически нет материала на русском языке касательного того, как правильно настроить работу 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
Следуем в Online и находим там SpecFlow.
Установка Specflow
Монтируем библиотеку. Программа «напомнит» о перезапуске Visual Studio.
2 Этап. Создание конфигурационного файла SpecFlow
Вы можете запросто пропустить этот шаг, если:
- В перспективе проверки всего лишь одна работа, и вы можете обходиться без экспериментальных сборок. В таком случае на 3 этапе просто скопируйте содержимое следующего файла конфигурации и вставьте внутрь своего.
Необходимо заранее приготовить файл 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
После редактирования настроек конфигурации SpecFlow самостоятельно будет обрабатывать программные возможности по новой.
4 Этап. Внесение документа с обоснованием ошибки
Вносим в проект SpecFlow фича-файл:
Файл SpecFlow Feature
Данный документ содержит специальный образец на английском языке. Так как мы настраиваем SpecFlow исключительно для русского языка, подсветка программного синтаксиса расшифрована не будет и проект технически не сможет распознать традиционные «Given/ When/Then».
Шаблон файла SpecFlow Feature
Структуру непосредственно шаблона можно запросто изменить на свое усмотрение.
Пришло время детально описать фичу на русском языке:
Описание фичи на русском языке
К слову, при описании нужно помнить, какие именно ключевые слова и фразы ставятся исключительно с английской версией:
Ключевые слова
Теперь есть все предпосылки, дабы убедится в том, что заданная конфигурация применена успешно и внесенные ключевые слова на русском языке правильно опознаются системой:
Ключевые слова на русском языке
5 Этап. Процесс создания тестовых проверок
Внутри документа проводим запуск из системного меню специального обработчика проверочных этапов:
Обработчик проверочных этапов
Если есть сомнения, можно повторно проверить, все ли функционирует верно и внутри созданного сценария найдены «Если», «И», «После», «Тогда».
Кнопка Generate
Кнопка Generate проводит процесс запуска необходимых этапов генерации.
Разрешается все сохранить, как предлагает система, либо же переименовать на свое усмотрение. Если честно, это очень рационально, когда все файлы с тестовыми шагами на 100% идентичны с фича-документами по наименованию проверяемой функции, а значит, рекомендуется с самого начала правильно назвать фичу.
В итоге у вас должны сгенерироваться такие шаги со специальными «cup» для программного кода для автоматических тестов:
Шаги со специальными cup
6 Этап. Запуск записанных тестов
И вот теперь до начала создания автоматического теста уже можно запустить ручной тест и убедится в том, что все функционирует максимально правильно.
Выполнить эту работу удобнее всего непосредственно с помощью контекстного меню внутри фича-документа:
Контекстное меню
Если все параметры заданы верно, а тест распознается системой как недописанный, то его старт не происходит:
Сбой старта теста
На рисунке показаны невыполненные проверки. Nunit начинает работать со всеми проверками по новой.
Если в системе определенные тесты функционируют неправильно, то проверка однозначно не выполнится еще до начала работы над автотестами. В самом плохом случае Nunit автоматически решит, что проверки вообще не были созданы.
В заключение
Ну а потом можно на свое усмотрение добавлять к уже имеющимся автотестам новые сценарии и таким образом существенно увеличивать набор имеющихся фича-файлов и тестовых сценариев.
Оставить комментарий