Cuke4Nuke还是SpecFlow？

Question

我试图决定是否应该使用Cuke4Nuke或SpecFlow.每个人的利弊是什么？关于哪个更好的观点和原因.

谢谢!

Answer 1

(我可能有偏见,因为我参与了SpecFlow,但我的想法......)

Cuke4Nuke非常接近Cucumber.这有很多优点:

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

然而,这也存在一些潜在的缺点:

• Ruby是必需品
• 由于涉及更多的基础设施(Ruby,有线协议,命令行集成......),整个解决方案的复杂性增加,并且链中的某些东西失败的可能性上升
• 调试是可能的,但有点麻烦
• 在DOS命令行上运行方案简直太丑了,我仍然遇到一些字符问题(德语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中的报告还不是很复杂.黄瓜确实提供了更多选择,但我不知道它们是否全部都可用于cuke4nuke ......

Answer 2

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

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

我遇到了一些问题,其中Cuke4Nuke不像Cucumber那样有效.但由于我主要使用英语,我在正常工作中看不到语言相关的问题.我欢迎重现任何这些问题的步骤,以便我可以解决它们.(请向他们发布Cuke4Nuke问题列表,而不是这里.)

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并支持将一些Cuk4Nuke功能移植到SpecFlow中.所以现在明确的答案是SpecFlow.

Answer 6

我从Cuke4Nuke开始,但后来叛逃到SpecFlow(对不起Richard ;-)

我进行这种转变的主要原因是:

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

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

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

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