Cuke4Nuke или SpecFlow?

(Я могу быть предвзятым, потому что я связан со SpecFlow, но вот мои мысли ...)

Cuke4Nuke очень близок к Cucumber. Это сулит множество преимуществ:

• Совместимость
• Получение новых функций от Cucumber при развитии Cucumber (по крайней мере, теоретически, но языковая поддержка является примером для этого)
• Быть реальной частью сообщества огурцов и экосистемы огурцов

Однако это также имеет некоторые потенциальные недостатки:

• Рубин - необходимость
• Поскольку задействовано больше инфраструктуры (Ruby, Wire-Protocol, интеграция с командной строкой ...), сложность всего решения возрастает, и вероятность того, что что-то в цепочке выходит из строя, возрастает.
• Отладка возможна, но это немного хлопот
• Запуск сценариев в командной строке dos просто уродлив, и у меня все еще есть проблемы с некоторыми символами (немецкий Umlaute). В моем случае решения от Cucumber не работали для cuke4nuke.
• Интеграция с вашей непрерывной сборкой - это то, что вам нужно решить для себя

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

SpecFlow пытается предложить следующие преимущества:

• Чистое решение .NET (поэтому установка Ruby не требуется, а Ruby не задействован во время выполнения)
• Имеется базовая интеграция с VisualStudio (и есть планы по ее развитию).
• Сценарии в основном представляют собой модульные тесты и могут быть запущены с вашей существующей инфраструктурой (NUnit.Runners, ReSharper, VisualStudio MSTest Integration ...)
• Сценарии и шаги легко отлаживать из VisualStudio (просто установите точку останова)
• Интеграция в вашу непрерывную сборку должна быть легкой, поскольку инфраструктура для запуска модульных тестов наверняка уже есть.

В качестве недостатков SpecFlow я сейчас вижу:

• Он не поддерживает столько языков, сколько Cucumber.
• В настоящее время задействован этап «генерации кода». Это прозрачно при использовании VisualStudio, и для этого есть командная строка без VisualStudio, но многим людям не нравится генерация кода.
• В настоящее время для SpecFlow не существует явного средства запуска командной строки. Однако вы можете использовать средство запуска командной строки модульного теста.
• SpecFlow зависит от инфраструктуры модульного тестирования, и в настоящее время поддерживаются только NUnit и MSTest.
• Отчетность в SpecFlow еще не очень сложна. Огурец действительно предлагает больше вариантов, однако я не знаю, все ли они доступны в cuke4nuke ...

jbandi дает хорошее резюме. Я отвечаю на этот вопрос примерно так же (конечно, с противоположной оговоркой о предвзятости).

Целью Cuke4Nuke является полная совместимость Cucumber с .NET при дублировании как можно меньшего количества кода Cucumber. Таким образом, некоторые из отмеченных вами компромиссов - например, Зависимость Ruby - присуща инструменту. Другие, такие как ошибки в поддержке языка и средства форматирования и ограниченная поддержка отладки, являются временными проблемами и исчезнут в будущих версиях.

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

Еще одно крайне предвзятое мнение: попробуйте StoryQ :)

Тесты StoryQ на самом деле представляют собой код, поэтому вы получаете гораздо лучшую поддержку рефакторинга / IDE, и он встраивается в ваш существующий модуль запуска модульных тестов, поэтому CI - легкий ветерок.

Вероятно, это вопрос предпочтений, предпочитаете ли вы проверять текстовые функции или компилируемый код. Но для нас мы обнаружили, что было действительно приятно иметь возможность переименовывать методы повествования и обновлять все истории.

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

Попробуйте, если вам нужна сверхлегкая точка входа в BDD :)

Другой предвзятый ответ: StorEvil съедает все другие инструменты .NET BDD.

Преимущества: у StorEvil есть собственная программа запуска командной строки, хорошая отчетность (с использованием механизма представления Spark) и лучший механизм перевода и выполнения в виде открытого текста -> C #.

Кроме того, в нем на 100% больше Зла, чем в любом другом решении.

Недостатки: StorEvil не полностью поддерживает другие человеческие языки (кроме английского). Интеграция StorEvil с Visual Studio пока не так хороша, как другие инструменты. StorEvil выпьет все пиво из холодильника, если вы не будете за ним следить.

Насколько я понимаю от Ричарда, он намеревается прекратить поддержку Cuke4Nuke и поддерживает перенос некоторых функций Cuk4Nuke в SpecFlow. Итак, теперь ясный ответ - SpecFlow.

Я начал с Cuke4Nuke, но с тех пор перешел на SpecFlow (извините, Ричард ;-)

Основными причинами, по которым я сделал этот переход, были:

• SpecFlow имеет отличную интеграцию с VS2010 для подсветки синтаксиса функций. Существует проект Cuke4VS, который предлагает подобное, но у него нет поддержки VS2010 (или нет, когда я все равно в последний раз смотрел, что было довольно недавно)
• Я обнаружил, что отладочные тесты в SpecFlow проще (не просите меня вдаваться в подробности, это просто так казалось ... ;-)
• Cuke4Nuke нужен Ruby. Я был в порядке с этим, но большинство разработчиков C #, которых я знаю, пугаются любых продуктов, отличных от MS, в частности Ruby.

Есть некоторые проблемы со Specflow / вещами, которые мне больше нравятся в мире Cucumber / Cuke4Nuke:

• Документация Specflow довольно «облегченная» - вам нужно будет быть готовым усердно работать, чтобы собрать информацию из источников Cucumber и немного интуитивно понять, как они применяются к Specflow. Тем не менее, я и несколько других планируем улучшить документацию, чтобы она могла улучшиться в течение следующих нескольких месяцев.
• Я предпочитаю запускать тесты Cucumber / Cuke4Nuke в командной строке с их выводом сценариев с цветовой кодировкой в ​​соответствии со статусом (я знаю, что кто-то выше видит это как отрицательный, поэтому я думаю, это зависит от того, являетесь ли вы типом командной строки парень...)
• Сообщество Cucumber больше, и кажется, что там больше активности, что (возможно) переводит больше людей, чтобы помочь вам.

В целом, у обоих есть потенциал для улучшения того, как мы пишем программное обеспечение.