Cuke4Nuke还是SpecFlow？

Question

我正在尝试决定是否应该使用Cuke4Nuke或SpecFlow。 每个人的利弊是什么？关于哪个更好的意见和原因。

谢谢！

Answer 1

（我可能有偏见，因为我参与了SpecFlow，但我的想法......）

Cuke4Nuke与Cucumber非常接近。 这有很多优点：

• 兼容性
• 在Cucumber发展时从Cucumber获取新功能（至少在理论上，但语言支持就是一个例子）
• 成为黄瓜社区和黄瓜生态系统的真正组成部分

然而，这也有一些潜在的缺点：

• Ruby是必需品
• 由于涉及更多基础设施（Ruby，有线协议，命令行集成......），整个解决方案的复杂性增加，并且链中的某些内容失败的可能性上升
• 可以调试，但有点hassle
• 在dos命令行上运行方案简直太丑了，我仍然遇到一些字符问题（德语Umlaute）。在我的案例中，来自Cucumber的solutions对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中的报告还不是很复杂。黄瓜确实提供了更多的选择，但是我不知道它们是否都可以用于cuke4nuke ......

Answer 2

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

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

我遇到了一些Cuke4Nuke不像Cucumber那样有效的问题。但由于我主要使用英语，我在正常工作中看不到语言相关的问题。我欢迎重现任何这些问题的步骤，以便我可以解决它们。 （请发帖给他们the Cuke4Nuke issues list，而不是这里。）

Answer 3

另一个有偏见的观点：尝试StoryQ：）

StoryQ测试实际上是代码，因此您可以获得更好的重构/ IDE支持，并且它嵌入在您现有的单元测试运行器中，因此CI是轻而易举的。

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

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

如果您想要一个超轻量级的BDD入口点，请试一试：）

Answer 4

另一个有偏见的回复：StorEvil吃掉所有其他.NET BDD工具。

优势：StorEvil拥有自己的命令行运行程序，具有良好的报告功能（使用Spark视图引擎），并具有最佳的纯文本 - ＆gt; C＃转换和执行引擎。

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

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

Answer 5

我从理查德了解到他打算停止使用Cuke4Nuke并支持将部分Cuk4Nuke功能移植到SpecFlow中。所以现在明确的答案是SpecFlow。

Answer 6

我从Cuke4Nuke开始，但后来叛逃到SpecFlow（对不起理查德; - ）

我做出这种转变的主要原因是：

• SpecFlow具有很好的VS2010集成功能，可以突出显示功能。有一个Cuke4VS项目提供类似但它没有VS2010支持（或者当我最后一次看时没有，这是最近的）
• 我发现SpecFlow中的调试测试更容易（不要让我详细说明，只是这样......; - ）
• Cuke4Nuke需要Ruby。我对此很满意，但我认识的大多数C＃开发者都被任何非MS产品吓到了，特别是Ruby。

在Cucumber / Cuke4Nuke世界中，Specflow /我更喜欢的东西有一些问题：

• Specflow的文档很简单 - 您必须准备好努力从Cucumber源收集信息并直接了解它们如何应用于Specflow。这说明我自己和其他几个人都在加强文档的设计，以便在接下来的几个月里有所改进。
• 我更喜欢在命令行上运行Cucumber / Cuke4Nuke测试的经验，他们根据状态颜色编码的场景输出（我知道上面有人认为这是负面的，所以我想这取决于你是否是一个命令那种人...）
• Cucumber社区规模更大，似乎有更多的活动（可能）转化为更多的人来帮助你。

总而言之，两者都有可能改善我们编写软件的方式。