Cuke4Nuke или SpecFlow?

Question

Я пытаюсь решить, использовать ли мне Cuke4Nuke или SpecFlow. Каковы плюсы / минусы каждого? Мнения о том, что лучше и почему.

Спасибо!

Answer 1

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

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

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

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

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

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

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

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

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

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

Answer 2

Другое сильно пристрастное мнение: Попробуйте StoryQ :)

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

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

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

Если хотите сверхлегкую точку входа в BDD:)

Answer 3

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

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

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

Answer 4

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

Answer 5

Еще один предвзятый ответ: StorEvil съедает все остальные инструменты .NET BDD.

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

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

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

Answer 6

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

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

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

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

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

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