Cuke4Nuke или SpecFlow?

Ответ 1

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

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

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

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

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

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

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

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

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

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

Ответ 2

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

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

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

Ответ 3

Еще одно сильно предвзятое мнение: Try StoryQ:)

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

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

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

Отдайте это, если вы хотите получить ультралегкую точку входа в BDD:)

Ответ 4

Другой смещенный ответ: StorEvil использует все другие инструменты .NET BDD.

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

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

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

Ответ 5

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

Ответ 6

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

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

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

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

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

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