Cuke4Nuke或SpecFlow？

Question

我想决定是否应该使用Cuke4Nuke或SpecFlow。 每个项目的优缺点是什么？关于哪个更好，为什么。

谢谢！

Answer 1

（我可能有偏差，因为我参与到SpecFlow，但在这里，我的想法...）

Cuke4Nuke是非常接近的黄瓜。 这个承诺很多优势：

• 兼容性
• 获得新功能，从黄瓜当黄瓜演变（至少在理论上，但语言支持是一个这样的例子）是的实部
• 黄瓜社会和生态黄瓜

然而，这还附带了一些潜在的缺点：

• Ruby是一种必然
• 由于更多的基础设施（红宝石，线协议，命令行整合......）参与，在整个解决方案的复杂度的提高，以及机会的东西链未能上升
• 调试是可能的，但有点hassle
• 在DOS命令行上运行的场景是简单的丑陋，我仍然有一些字符（德国Umlaute）的问题。来自Cucumber的solutions在我的情况下不适用于cuke4nuke。
• 整合您持续构建的是你得把自己的东西

SpecFlow是从黄瓜一个单独的项目。它试图尽可能地接近黄瓜，但是存在并将存在差距。有计划使用与Cucumber相同的解析器来提高语言级别的兼容性。

SpecFlow试图提供以下优点：

• 纯.NET溶液（所以没有安装红宝石是必要的和Ruby不会在运行时参与）
• 没有与VisualStudio的一个基本的集成（并有计划地发展本）
• 方案基本上是单元测试，可与现有的基础设施（NUnit.Runners，ReSharper的，VisualStudio的MSTest的集成运行...）
• 方案和步骤，很容易调试的出VisualStud的IO（只是设置一个断点）在你的持续构建
• 整合应该是轻而易举的事，因为基础架构来运行单元测试是肯定存在已经

由于SpecFlow的缺点我看到目前：

• 它不支持与Cucumber一样多的语言
• 当前有一个“代码生成”步骤涉及。使用VisualStudio时这是透明的，并且有一个命令行可以在没有VisualStudio的情况下执行此操作，但很多人不喜欢代码生成。
• 目前没有用于SpecFlow的明确的命令行转轮。但是，你可以使用你的单元测试命令行亚军。
• SpecFlow依赖于单元测试框架，目前只支持NUnit和MSTest
• SpecFlow中的报表还不是很复杂。黄瓜确实提供了更多的选择，但是我不知道它们是否都可用于cuke4nuke ...

Answer 2

jbandi给出了一个很好的总结。我以同样的方式回答了这个问题（当然，对于偏见的反对声明）。

Cuke4Nuke的目标是在.NET中完全兼容黄瓜，同时尽可能复制尽可能少的黄瓜代码。因此，您强调的一些权衡 - 例如， Ruby依赖项 - 是该工具固有的。其他的，比如语言和格式化支持中的错误以及有限的调试支持，都是暂时的问题，将会在未来的版本中消失。

我遇到了一些Cuke4Nuke不能很像黄瓜一样工作的问题。但是因为我主要用英语工作，所以在正常工作中我没有看到语言相关的问题。我很欢迎重现这些问题的步骤，以便我可以修复它们。 （请邮寄给他们the Cuke4Nuke issues list，不是在这里。）

Answer 3

另一个严重偏见的意见：尝试StoryQ :)

StoryQ测试实际上是代码，让您获得更好的重构/ IDE的支持，它现有的内嵌入单元测试亚军，所以CI是一件轻而易举的事。

这可能是您偏好检查纯文本功能还是可编译代码的问题。但对我们来说，我们发现能够重新命名叙事方法并让所有故事更新自己真的很棒。

实际上提供了一个GUI，可以将纯文本场景转换为StoryQ代码，如果您已经对明文场景进行了投资或想要将键盘交给商务人士。它甚至有一个简单的智能感知形式！

如果你想要一个超轻量级的切入点BDD :)给它一个去

Answer 4

另一个偏颇回应：StorEvil吃所有其他.NET BDD工具。

优点：StorEvil有自己的命令行转轮，有很好的报告（使用Spark视图引擎），并且具有最好的纯文本 - > C＃翻译和执行引擎。

此外，它比任何其他解决方案都多100％。

缺点：StorEvil不完全支持其他人类语言（英语除外）。 StorEvil的Visual Studio集成还不如其他工具。如果你不注意，StorEvil会把冰箱里的所有啤酒都喝下去。

Answer 5

我开始与Cuke4Nuke但此后投奔SpecFlow（对不起理查德;-)

对我来说，主要的原因使这一过渡是：

• SpecFlow具有的语法高亮不错VS2010整合特征。有一个Cuke4VS项目提供类似的功能，但它没有VS2010的支持（或者当我上次查看时，这是相当近的）
• 我发现SpecFlow中的调试测试更容易（不要问我详细说明，它似乎就是这样...... ;-)
• Cuke4Nuke需要Ruby。我确定，但是我知道的大多数C＃开发人员都会被任何非MS产品吓到，尤其是Ruby。

有一些问题与Specflow /东西我都喜欢在黄瓜/ Cuke4Nuke世界更美好：

• Specflow的文档是很“精简版” - 你必须准备努力工作，收集来自黄瓜来源的信息和直觉有点适用于Specflow。这就是说，我自己和其他几个人都没有设计加强文档，以便在未来几个月内可以改进。
• 我更喜欢在命令行上运行Cucumber/Cuke4Nuke测试的经验，他们根据状态输出场景颜色代码（我知道上面的人认为这是负面的，所以我猜这取决于你是否是命令线型的家伙......）
• 黄瓜社区更大，有更多的活动，似乎（可能）转化为更多的人在那里帮助你。

总而言之，这两方面都有改进我们编写软件的方式的潜力。

Answer 6

我从理查德了解到他打算停止Cuke4Nuke并支持将一些Cuk4Nuke功能移入SpecFlow。所以现在明确的答案是SpecFlow。