39

我正在尝试决定是否应该使用 Cuke4Nuke 或 SpecFlow。每个的优点/缺点是什么？关于哪个更好以及为什么更好的意见。

谢谢！

4

6 回答 6

60

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

Cuke4Nuke 非常接近 Cucumber。这保证了很多优点：

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

然而，这也带来了一些潜在的缺点：

  • 红宝石是必需品
  • 由于涉及到更多的基础设施（Ruby、Wire-Protocol、命令行集成......），整个解决方案的复杂性增加了，链中的某些东西失败的可能性也增加了
  • 调试是可能的，但有点麻烦
  • 在 dos 命令行上运行场景简直丑陋，而且我仍然对某些字符（德语变音符号）有问题。就我而言，Cucumber的解决方案不适用于 cuke4nuke。
  • 与您的持续构建集成是您必须自己解决的问题

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

SpecFlow 试图提供以下优势：

  • 纯 .NET 解决方案（因此无需安装 Ruby，并且运行时不涉及 Ruby）
  • 与 VisualStudio 有一个基本的集成（并且有计划对此进行改进）
  • 场景基本上是单元测试，可以与您现有的基础设施（NUnit.Runners、ReSharper、VisualStudio MSTest Integration ...）一起运行
  • 场景和步骤很容易从 VisualStudio 中调试出来（只需设置一个断点）
  • 集成到您的持续构建中应该是轻而易举的事，因为运行单元测试的基础设施肯定已经存在

我目前看到的 SpecFlow 的缺点：

  • 它不支持像 Cucumber 那么多的语言
  • 目前有一个“代码生成”步骤。这在使用 VisualStudio 时是透明的，并且在没有 VisualStudio 的情况下有一个命令行可以做到这一点，但是很多人不喜欢代码生成。
  • 目前 SpecFlow 没有明确的命令行运行程序。但是，您可以使用您的单元测试命令行运行程序。
  • SpecFlow 依赖于 Unit-Test 框架，目前仅支持 NUnit 和 MSTest
  • SpecFlow 中的报告还不是很复杂。Cucumber 确实提供了更多选择，但我不知道它们是否都在 cuke4nuke 中可用......
于 2010-01-22T10:27:53.337 回答
11

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

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

我遇到了一些 Cuke4Nuke 不像 Cucumber 那样工作的问题。但由于我主要以英语工作，我在正常工作中看不到与语言相关的问题。我欢迎重现这些问题的步骤，以便我可以修复它们。（请向他们发布Cuke4Nuke 问题列表，而不是此处。）

于 2010-01-23T11:43:18.793 回答
11

另一个严重偏见的观点：试试StoryQ :)

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

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

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

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

于 2010-02-05T17:09:18.897 回答
7

另一个有偏见的回应：StorEvil吞噬了所有其他 .NET BDD 工具。

优点： StorEvil 有自己的命令行运行器，有很好的报告（使用 Spark 视图引擎），并且有最好的明文->C# 翻译和执行引擎。

此外，它比任何其他解决方案都多 100% 的邪恶。

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

于 2010-06-29T22:27:28.600 回答
7

我从 Richard 那里了解到，他打算停止使用 Cuke4Nuke，并支持将 Cuk4Nuke 的一些功能转移到 SpecFlow 中。所以现在明确的答案是 SpecFlow。

于 2011-08-25T06:33:52.050 回答
6

我从 Cuke4Nuke 开始，但后来叛逃到 SpecFlow（抱歉，Richard ;-)

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

  • SpecFlow 具有很好的 VS2010 集成，可用于功能的语法突出显示。有一个 Cuke4VS 项目提供类似的功能，但它没有 VS2010 支持（或者在我上次查看时没有，这是相当新的）
  • 我发现 SpecFlow 中的调试测试更容易（不要让我详细说明，看起来就是这样...... ;-)
  • Cuke4Nuke 需要 Ruby。我对此没意见，但我认识的大多数 C# 开发人员都会被任何非 MS 产品吓到，尤其是 Ruby。

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

  • Specflow 的文档非常“精简”——您必须准备好努力从 Cucumber 来源收集信息，并直观地了解它们如何应用于 Specflow。那就是说我和其他人很少有设计来加强文档，以便在接下来的几个月内有所改善。
  • 我更喜欢在命令行上运行 Cucumber/Cuke4Nuke 测试的体验，它们根据状态对场景进行颜色编码（我知道上面有人认为这是负面的，所以我想这取决于你是否是命令行类型伙计……）
  • Cucumber 社区更大，似乎有更多的活动，这（可能）转化为更多的人来帮助你。

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

于 2011-02-15T19:04:41.927 回答