Здравствуйте, коллеги!
Обьект тестирования - веб - приложение. Инструменты - Selenium WD, C#, Specflow.
По мере написания новых тестовых сценариев количество фич растет - поэтому возник вопрос - не использует ли кто-нибудь из Вас BDD фреймворк Specflow?
Не могли бы Вы дать совет какую структуру файлов в проекте лучше использовать.
И как организованы тесты в проекте у Вас?
Заранее благодарен за ответ.
Структура подпапка «Features» логически напоминала саму структуру продукта. Папка «CurrentSprint» – не содержала под папок.
После того, как функциональность сдана. Я переносил все готовые фичи из «CurrentSprint» в «Features».
Если я правильно понял суть проблемы, которую решала папка с названием “CurrentSprint” - с ней вполне способна справиться система контроля версий (если она используется не только разрабами), с соответствующими названиями branches, tags и т.д.
Acceptance тесты - это фактически живая документация системы, и она должна соответствовать ее текущему состоянию.
Если “шаги” еще не готовы и дописываются уже после того, как разрабы наваяют код (в суровой реальности) - можно просто помечать подобные сценарии тэгом @ignore, тогда Specflow будет генерировать для него “ignored” тесты. Можно также использовать какой-нибудь другой тэг, но тогда нужно будет позаботиться об отдельной фильтрации этого тэга при прогоне тестов, используя, например, Scoped Bindings
Для «StepDefinitions» лучше повторить такую же структуру как и в «Features».
Также, я не создавал общих и «переиспользуемых шагов». Для каждой фичи я создавал и привязывал отдельный StepDefinition-файл.
С «общими шагами» мне было очень неудобно работать и поддерживать.
Хотел бы отметить, что жесткое связывание структуры “фич” и “шагов”, вообще говоря, считается анти-паттерном. Об этом можно почитать здесь (eng).
Текущая интеграция SpecFlow с Visual Studio позволяет спокойно перемещаться к имплементациям “шагов” из “фич”, как в редакторе, так и в классическом окне Test Explorer. Так что непонятно, зачем нужно отказываться от принципов повторного использования кода, и “гладить ATDD framework против шерсти”.
В той же документации по Cucumber советуют использовать доменный подход в организации “шагов” (eng).
В дополнение хочу сказать, что рано или поздно потребуется писать дополнительные хуки подготовки и очистки тестов уровня сценария, фичи или всего тестового запуска. Для этого можно создать отдельный Hooks.cs в папке StepDefinitions\ либо создать отдельную папку Hooks\
@somaritane, спасибо за ответ.
Должен сказать, что мой комментарий был написан почти 2 года назад, и понаслышке я знаю, что Specflow за это время качественно изменился в лучшую сторону, даже появился плагин для создания сценариев в Excel и была улучшена работа плагина, встроенного в Visual Studio…
Но, в свое время, а это два или полтора года назад, я отказался от использования SpecFlow и перешел на BDDfy который генерировал красивые отчёты и позволял более удобно работать с кодом… и в последствии, почерпнув лучшее для себя из обеих фреймворков, а именно: короткие и читабельные тесты + понятные отчёты, я решил написать свой. К слову, BDDfy мне и до сих пор очень нравится и может быть, я к нему ещё вернусь.
Причины: Gherkin (Given When Then)… это конечно же крутой язык, но для некоторых кейсов – очень избыточный. Иногда GWT очень хорошо подходит для описания сценария… но, иногда, когда нужно написать короткий простой тест, состоящий из одного заголовка… то синтаксис Gherkin требует наличие хотя бы одного или двух шагов…
Я понял, для меня проще написать вот так:
testomat.io управление авто тестами[TestMethod]
public void It_should_show_warning_when_username_is_empty()
{
TestRequiredField(MyPages.RegisterUserForm, "txtUsername", required : true);
}
А красивый отчет и лог прохода получить автоматически, через AOP, после прогона теста.
Спасибо за наводку про BDDfy! Обязательно посмотрю.
Согласен насчет использования Gherkin, да и любых других external DSL языков вообще.
Это красиво, но вся красота заканчивается, когда команда понимает, что все это, кроме них, никому не нужно.
Спецификации должен писать Product Owner, сам, при помощи команды, бизнес аналитика - не важно.
Если он не видит смысла в написании и поддержке сценариев, если для него даже текст с отступами - это слишком сложно, если ответственным лицам продукта не интересна документация и состояние acceptance tests - команда может спокойно выкидывать Gherkin из окна и использовать internal DSL.
Полностью поддерживаю, так у меня и произошло