Step-by-step: настройка SpecFlow для русскоязычного проекта при написании тестов в среде .Net

от автора

Не нашла в интернете пошаговой русскоязычной инструкции о том, как настроить SpecFlow на работу с русскими спецификациями. Да и вообще нет русской инструкции о том, как начать работать со SpecFlow. Зато обнаружила некоторый скепсис у других автоматизаторов по поводу того, что это можно сделать легко и просто, однако предложенные альтернативы мне не приглянулись в далекой перспективе (просмотр тестов с веба специалистами технической поддержки). Мне нужен именно SpecFlow и именно по-русски!

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

Эта статья полезна для тех, кто:

  • оценивает перспективы применения Specification by Example (BDD) подхода к автоматизации тестирования, и хочет описывать фичи и сценарии на русском языке, и хочет оценить scope работ;
  • хочет как можно быстрее начать применять BDD в своем проекте.

Эта статья бесполезна для тех, кто:

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

Постановка задачи

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

Руководство дало добро попробовать применить самые современные тенденции автоматизации — Specification By Example, пообещав выделить ключевой функционал, автоматизация которого имеет высочайший приоритет, и описать его в виде простых и понятных User Story.

Что делать дальше? Расписывать сценарии непосредственно в feature-файлах и прикручивать их к автотестам!

Инструкция

Что понадобится

  1. IDE для .Net. Инструкция написана для англоязычной Visual Studio 2012. В других IDE действовать по аналогии.
  2. Выбрать и установить Test Runner, если его еще нет. Я пользуюсь NUnit. SpecFlow также поддерживает и другие инструменты запуска тестов.
Шаг 1: установка SpecFlow

Заходим в Tools — Extentions and Updates.

Переходим в Online и ищем SpecFlow.

Устанавливаем расширение. Установщик попросит перезагрузить студию.

Шаг 2: создаём конфигурационный файл SpecFlow

Заранее подготовим файл App.config со следующим содержанием:

<?xml version="1.0" encoding="utf-8" ?> <configuration>   <configSections>     <section name="specFlow" type="TechTalk.SpecFlow.Configuration.ConfigurationSectionHandler, TechTalk.SpecFlow"/>   </configSections>   <specFlow>     <!-- For additional details on SpecFlow configuration options see http://go.specflow.org/doc-config -->     <unitTestProvider name="NUnit" />     <language feature="ru-RU" tool="ru-RU" />     <bindingCulture name="ru-RU" />   </specFlow>   </configuration> 

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

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

Шаг 3: создание проекта

Создаём проект типа Unit Test.

Из дерева проекта удаляем ненужный файл стандартного класса:

Запускаем консоль менеджера пакетов:

В нём запускаем команду:
PM> Install-Package SpecFlow.NUnit -ProjectName UnitTestProject1

После того как команда отработает, в папке проекта появится файл App.config. Его не видно в Solution Explorer.

Нужно заменить дефолтный конфиг на тот, который мы приготовили заранее. Можно сделать 2 способами:
1. Открыть папку проекта в файловой системе и поменять копипастом.
2. Добавить файл в дерево проекта:

Теперь можно отредактировать содержимое в самой студии:

Шаг 4: Добавление файла с описанием фичи

Добавляем в проект SpecFlow feature File:

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

Опишем фичу и сценарий по-русски (можно скопировать отсюда):

Функция: Аутентификация пользователя 	Для того чтобы пользоваться порталом 	Как пользователь 	Я хочу авторизоваться  @позитивный Сценарий: Успешная авторизация 	Допустим Я нахожусь на странице авторизации 	И я ввёл свой логин 	И я ввёл свой пароль 	Когда я нажимаю кнопку Login 	Тогда Браузер перенаправляет меня на домашнюю страницу 

При описании надо иметь в виду, какие именно ключевые слова ставятся в соответсвие с английскими:

<Language code="ru" cultureInfo="ru" defaultSpecificCulture="ru-RU" englishName="Russian">     <Feature>Функция</Feature>     <Feature>Функционал</Feature>     <Feature>Свойство</Feature>     <Background>Предыстория</Background>     <Background>Контекст</Background>     <Scenario>Сценарий</Scenario>     <ScenarioOutline>Структура сценария</ScenarioOutline>     <Examples>Примеры</Examples>     <Given>Допустим</Given>     <Given>Дано</Given>     <Given>Пусть</Given>     <When>Если</When>     <When>Когда</When>     <Then>То</Then>     <Then>Тогда</Then>     <And>И</And>     <And>К тому же</And>     <But>Но</But>     <But>А</But>   </Language> 

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

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

Шаг 5: Генерация тестовых шагов

В самом feature-файле запускаем из контекстного меню генератор тестовых шагов:

Можно убедиться еще раз, что всё правильно понимается, и в нашем сценарии нашлись все «Given», «And», «When», «Then»:

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

В итоге у нас сгенерировались шаги с заглушками для кода автотестов:

Шаг 6: Запуск теста

Теперь, еще до написания автотеста, уже можно запустить тест и убедиться, что все правильно работает.
Сделать это удобнее всего из контекстного меню в самом фича-файле:

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

На скриншоте заваленные тесты — из другого проекта в том же Solution. NUnit запускает все тесты сразу.

Если что-то настроено не так — тест завалится еще до написания начинки автотеста. В худшем случае — NUnit решит что тестов нет вообще.

Шишки

Я наивно пыталась переопределить ключевые слова в файле App.Config, написала там лишнего, и это привело к тому, что тест падал:
Result Message: TestFixtureSetUp failed in <Имя проекта>

Если пользуясь этой инструкцией вы всё-таки столкнётесь с «красными» результатами — пишите в комментариях, этот опыт может оказаться полезным кому-то.

А что дальше?

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

Исчтоники информации:

www.specflow.org/specflownew/ProjectSetupGuide.html
go.specflow.org/doc-config
github.com/techtalk/SpecFlow/wiki/Configuration
raw.github.com/techtalk/SpecFlow/master/Languages.xml
msdn.microsoft.com

ссылка на оригинал статьи http://habrahabr.ru/post/182160/


Комментарии

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *