Комментарии 4
Максим, есть еще такой фреймворк BDDfy, который вашу задачу (генерацию красивого отчета после прогона) может решить проще. BDDfy интегрируется с чем-угодно и может генерировать очень классные отчеты.
Примеры кода можно посмотреть тут, а в соседних папках есть та же реализация на SpecFlow
Дополнительные пояснения в этом посте
Примеры кода можно посмотреть тут, а в соседних папках есть та же реализация на SpecFlow
Дополнительные пояснения в этом посте
Спасибо за информацию. Fluent-синтаксис понравился особенно. А в чем преимущество тащить за собой еще одну технологию, если задача решается со SpecFlow одним базовым классом?
Отказываться от SpecFlow я не хочу, потому что DSL отлично работает на уровне управления требованиями. BDDfy уже очень близко к юнит-тестам.
Отказываться от SpecFlow я не хочу, потому что DSL отлично работает на уровне управления требованиями. BDDfy уже очень близко к юнит-тестам.
Да, вы правы, BDDfy действительно уж очень близок к юнит-тестам. Именно поэтому вам нет необходимости отказывается от Specflow.
Если у вас Unit-тест фреймворк – это NUnit, то BDDfy будет отлично на нем работать, как и на любом другом, как и любые другие тесты в юнит-тест стиле + будет красивый отчет.
Если хотите, то можете вызывать шаги из StepDefinitions которые на SpecFlow.
Исходную задачу вы спокойно можете решить и в обычном юнит тест стиле. И просто положить рядом и запускать тесты вместе. В посте, извините, получается каша из топора (где топор – это Specflow), которая в итоге будет без топора.
BDDfy к этому юнит тест-стилю может добавить красивый отчет.
Просто предназначение SpecFlow – это создание читабельных запускаемых спецификаций, которые могут прочитать люди из бизнеса. В данном случае это не достижимо, потому что спецификации находятся в коде, а код кроме тех кто его пишет – никто больше читать не будет.
В такой ситуации работать с BDDfy будет проще.
Например, вот эта строка из кода:
When(string.Format(«User fill {0} and {1}», a, b));
Получается, что вместо прямого вызова метода с двумя параметрами, происходит следующее:
1. Два значения преобразовываются в строку
2. Строка передается движку Specflow
3. Движок парсит строку и получает два параметра
4. Движок вызывает нужные метод и передает ему эти два параметра.
На мой взгляд, это немного накладно. Слишком длинный путь в котором многое может сломаться. + не используются функции Visual Studio, потому что идет работа через текстовые строки.
Если у вас Unit-тест фреймворк – это NUnit, то BDDfy будет отлично на нем работать, как и на любом другом, как и любые другие тесты в юнит-тест стиле + будет красивый отчет.
Если хотите, то можете вызывать шаги из StepDefinitions которые на SpecFlow.
Исходную задачу вы спокойно можете решить и в обычном юнит тест стиле. И просто положить рядом и запускать тесты вместе. В посте, извините, получается каша из топора (где топор – это Specflow), которая в итоге будет без топора.
BDDfy к этому юнит тест-стилю может добавить красивый отчет.
Просто предназначение SpecFlow – это создание читабельных запускаемых спецификаций, которые могут прочитать люди из бизнеса. В данном случае это не достижимо, потому что спецификации находятся в коде, а код кроме тех кто его пишет – никто больше читать не будет.
В такой ситуации работать с BDDfy будет проще.
Например, вот эта строка из кода:
When(string.Format(«User fill {0} and {1}», a, b));
Получается, что вместо прямого вызова метода с двумя параметрами, происходит следующее:
1. Два значения преобразовываются в строку
2. Строка передается движку Specflow
3. Движок парсит строку и получает два параметра
4. Движок вызывает нужные метод и передает ему эти два параметра.
На мой взгляд, это немного накладно. Слишком длинный путь в котором многое может сломаться. + не используются функции Visual Studio, потому что идет работа через текстовые строки.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Data Driven Tests & SpecFlow