Не нашла в интернете пошаговой русскоязычной инструкции о том, как настроить SpecFlow на работу с русскими спецификациями. Да и вообще нет русской инструкции о том, как начать работать со SpecFlow. Зато обнаружила некоторый скепсис у других автоматизаторов по поводу того, что это можно сделать легко и просто, однако предложенные альтернативы мне не приглянулись в далекой перспективе (просмотр тестов с веба специалистами технической поддержки). Мне нужен именно SpecFlow и именно по-русски!
Я все-таки как-то разобралась, и, чтобы другие не сомневались, что это не так уж и сложно сделать, и не набивали собственные шишки, делюсь своей инструкцией. Она прежде всего предназначена для тестировщиков-автоматизаторов, поэтому может содержать некоторые очевидные для программистов моменты.
Эта статья полезна для тех, кто:
Эта статья бесполезна для тех, кто:
Передо мной стоит задача автоматизировать тестирование ключевого функционала одного приложения, которое разрабатывается российской компанией и ориентировано, в основном, на отечественных потребителей. Приложение существует на рынке приличное количество лет, а документация по нему измеряется сотнями страниц. Релизы часты, багов полно, тестировщиков мало.
Руководство дало добро попробовать применить самые современные тенденции автоматизации — Specification By Example, пообещав выделить ключевой функционал, автоматизация которого имеет высочайший приоритет, и описать его в виде простых и понятных User Story.
Что делать дальше? Расписывать сценарии непосредственно в feature-файлах и прикручивать их к автотестам!
Заходим в Tools — Extentions and Updates.
Переходим в Online и ищем SpecFlow.
Устанавливаем расширение. Установщик попросит перезагрузить студию.
Этот шаг можно пропустить, если:
Заранее подготовим файл App.config со следующим содержанием:
Вместо NUnit здесь можно указать другой прогонщик тестов.
Этот файл нужно будет подкладывать во все проекты, содержащие наборы тестов и feature-файлы, поэтому лучше хранить его копию отдельно.
Ссылку на документацию в комментариях оставляю нарочно — вдруг захочется что-то ещё поменять.
Конфигурационный файл перетирает дефолтовые настройки SpecFlow, поэтому при использовании англоязычных спек с NUnit он не нужен.
Создаём проект типа Unit Test.
Из дерева проекта удаляем ненужный файл стандартного класса:
Запускаем консоль менеджера пакетов:
В нём запускаем команду:
Где:
UnitTestProject1 — имя Вашего проекта.
SpecFlow.NUnit — версия SpecFlow для NUnit. Можно написать просто SpecFlow, тогда тесты будут запускать не NUnit, а SpecRun. Подробнее тут.
После того как команда отработает, в папке проекта появится файл App.config. Его не видно в Solution Explorer.
Нужно заменить дефолтный конфиг на тот, который мы приготовили заранее. Можно сделать 2 способами:
1. Открыть папку проекта в файловой системе и поменять копипастом.
2. Добавить файл в дерево проекта:
Теперь можно отредактировать содержимое в самой студии:
Каждый раз после изменения конфигурации SpecFlow сам попросит разрешения обработать свои фичи заново.
Добавляем в проект SpecFlow feature File:
Этот файл будет содержать образец на английском языке. Поскольку мы настроили SpecFlow на русский, подсветка синтаксиса не сработает — проект не распознает теперь «Given / When / Then»:
Сам шаблон можно поменять, про это написано в комментарии.
Опишем фичу и сценарий по-русски (можно скопировать отсюда):
При описании надо иметь в виду, какие именно ключевые слова ставятся в соответсвие с английскими:
Для тех, кто считает что Gherkin формула «Given / When / Then» по-русски звучит как «Если / Когда / Тогда» обращаю особое внимание на то, что в SpecFlow «Если» соответствует «When», и я лично нахожу это вполне логичным. Попытки обойти это и сделать «Если» = «Given» заканчиваются путаницей и неразберихой при генерации шагов.
Теперь можно убедиться, что конфигурация удалась и русские ключевые слова опознаются:
В самом feature-файле запускаем из контекстного меню генератор тестовых шагов:
Можно убедиться еще раз, что всё правильно понимается, и в нашем сценарии нашлись все «Given», «And», «When», «Then»:
Generate — генерируем шаги.
Сохраняем как предложено или переименовываем. Вообще удобно, когда файлы с шагами теста совпадают с фича-файлами по названию тестируемой функции, поэтому лучше с самого начала правильно назвать фичу.
В итоге у нас сгенерировались шаги с заглушками для кода автотестов:
Теперь, еще до написания автотеста, уже можно запустить тест и убедиться, что все правильно работает.
Сделать это удобнее всего из контекстного меню в самом фича-файле:
Всё настроено верно, если тест распознаётся как недописаный и его запуск не происходит:
На скриншоте заваленные тесты — из другого проекта в том же Solution. NUnit запускает все тесты сразу.
Если что-то настроено не так — тест завалится еще до написания начинки автотеста. В худшем случае — NUnit решит что тестов нет вообще.
Я наивно пыталась переопределить ключевые слова в файле App.Config, написала там лишнего, и это привело к тому, что тест падал:
Если пользуясь этой инструкцией вы всё-таки столкнётесь с «красными» результатами — пишите в комментариях, этот опыт может оказаться полезным кому-то.
Дальше надо прикручивать автотесты к шагам и расширять ассортимент фича-файлов и сценариев. Как это делать по-русски активно разъясняет 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
Я все-таки как-то разобралась, и, чтобы другие не сомневались, что это не так уж и сложно сделать, и не набивали собственные шишки, делюсь своей инструкцией. Она прежде всего предназначена для тестировщиков-автоматизаторов, поэтому может содержать некоторые очевидные для программистов моменты.
Эта статья полезна для тех, кто:
- оценивает перспективы применения Specification by Example (BDD) подхода к автоматизации тестирования, и хочет описывать фичи и сценарии на русском языке, и хочет оценить scope работ;
- хочет как можно быстрее начать применять BDD в своем проекте.
Эта статья бесполезна для тех, кто:
- сам знает как это просто делается;
- готов потратить несколько часов работы + владеет английским языком достаточно хорошо, чтобы самому разобраться в инструкциях.
Постановка задачи
Передо мной стоит задача автоматизировать тестирование ключевого функционала одного приложения, которое разрабатывается российской компанией и ориентировано, в основном, на отечественных потребителей. Приложение существует на рынке приличное количество лет, а документация по нему измеряется сотнями страниц. Релизы часты, багов полно, тестировщиков мало.
Руководство дало добро попробовать применить самые современные тенденции автоматизации — Specification By Example, пообещав выделить ключевой функционал, автоматизация которого имеет высочайший приоритет, и описать его в виде простых и понятных User Story.
Что делать дальше? Расписывать сценарии непосредственно в feature-файлах и прикручивать их к автотестам!
Инструкция
Что понадобится
- IDE для .Net. Инструкция написана для англоязычной Visual Studio 2012. В других IDE действовать по аналогии.
- Выбрать и установить Test Runner, если его еще нет. Я пользуюсь NUnit. SpecFlow также поддерживает и другие инструменты запуска тестов.
Шаг 1: установка SpecFlow
Заходим в Tools — Extentions and Updates.
Переходим в Online и ищем SpecFlow.
Устанавливаем расширение. Установщик попросит перезагрузить студию.
Шаг 2: создаём конфигурационный файл SpecFlow
Этот шаг можно пропустить, если:
- У вас только 1 проект, и вы обходитесь без всяких черновиков и экспериментов. Тогда на шаге 3 скопируйте содержимое этого конфига и вставьте в свой.
- Вы воспользуетесь советом из комментария.
Заранее подготовим файл 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Где:
UnitTestProject1 — имя Вашего проекта.
SpecFlow.NUnit — версия SpecFlow для NUnit. Можно написать просто SpecFlow, тогда тесты будут запускать не NUnit, а SpecRun. Подробнее тут.
После того как команда отработает, в папке проекта появится файл App.config. Его не видно в Solution Explorer.
Нужно заменить дефолтный конфиг на тот, который мы приготовили заранее. Можно сделать 2 способами:
1. Открыть папку проекта в файловой системе и поменять копипастом.
2. Добавить файл в дерево проекта:
Теперь можно отредактировать содержимое в самой студии:
Каждый раз после изменения конфигурации SpecFlow сам попросит разрешения обработать свои фичи заново.
Шаг 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
