Cuke4Nuke或SpecFlow？
我正在决定是否应该使用Cuke4Nuke或SpecFlow。 什么是每个人的利弊？ 意见哪个更好，为什么。
谢谢！
（我可能有偏见，因为我参与SpecFlow，但在这里我的想法…）
Cuke4Nuke非常接近黄瓜。 这承诺很多好处：
- 兼容性
- 当黄瓜发育时，从黄瓜获得新的特征（至less在理论上，但语言支持就是这样一个例子）
- 作为黄瓜社区和黄瓜生态系统的一部分
然而这也带来一些潜在的缺点：
- ruby是必需品
- 由于涉及到更多的基础设施（Ruby，Wire-Protocol，命令行集成等），整个解决scheme的复杂性上升，并且链中的某些东西失败
- debugging是可能的，但有点麻烦
- 在dos命令行上运行场景简直是丑陋的，我仍然有一些字符（德国Umlaute）的问题。 黄瓜的解决scheme在我的情况下不适用于cuke4nuke。
- 与持续构build的集成是你必须自己解决的
SpecFlow是一个来自Cucumber的独立项目。 它尽可能接近黄瓜，但有和将会有差距。 有计划使用与Cucumber相同的parsing器来提高语言级别的兼容性。
SpecFlow试图提供以下优点：
- 一个纯粹的.NET解决scheme（所以不需要安装Ruby，而Ruby在运行时不参与）
- 与VisualStudio有一个基本的整合（并且有计划演变这个）
- scheme基本上是UnitTests，可以与您现有的基础架构（NUnit.Runners，ReSharper，VisualStudio MSTest集成…）一起运行
- 场景和步骤很容易从VisualStudio中debugging（只需设置一个断点）
- 在持续构build中的集成应该是一件轻而易举的事情，因为运行unit testing的基础架构已经确定了
我目前看到SpecFlow的缺点：
- 它不支持和黄瓜一样多的语言
- 目前有一个“代码生成”步骤。 这在使用VisualStudio时是透明的，并且没有VisualStudio就有一个命令行来做，但很多人不喜欢代码生成。
- 目前没有明确的命令行亚军SpecFlow。 但是你可以使用你的unit testing命令行亚军。
- SpecFlow依赖于unit testing框架，目前只支持NUnit和MSTest
- 在SpecFlow中的报告还不是很复杂。 黄瓜确实提供了更多的select，但是我不知道他们是否都可以在cuke4nuke …
jbandi给出了一个很好的总结。 我以同样的方式回答这个问题（当然，对于偏见的反对声明）。
Cuke4Nuke的目标是在.NET中完全兼容Cucumber，同时尽可能less复制Cucumber代码。 因此，您强调的一些权衡（例如，Ruby依赖）是该工具固有的。 其他的，像语言和格式化程序支持中的错误以及有限的debugging支持，都是暂时的问题，将会在未来的版本中消失。
我遇到了一些Cuke4Nuke和黄瓜不一样的问题。 但是，由于我主要用英语工作，在正常工作中我没有看到与语言有关的问题。 我很欢迎重现这些问题的步骤，所以我可以解决它们。 （请发布给他们Cuke4Nuke问题列表 ，不在这里。）
另一个严重的偏见：尝试StoryQ 🙂
StoryQtesting实际上是代码，所以你可以获得更好的重构/ IDE支持，并且embedded到现有的unit testing运行器中，所以CI是一件轻而易举的事情。
这可能是一个偏好的问题，你是否宁愿检查纯文本function或编译代码。 但是对于我们来说，我们发现能够重新命名叙事方法并且让所有的故事更新自己是非常好的。
实际上，提供了一个GUI，可以将纯文本场景转换为StoryQ代码，如果您已经对明文场景进行了投资，或者希望将键盘交给业务人员。 它甚至有一个简单的智能forms！
如果你想要一个超轻量级的入口点进入BDD，请试试吧:)
另一个偏见的回应： StorEvil吃所有其他的.NET BDD工具。
优点 ：StorEvil拥有自己的命令行转轮，具有良好的报告（使用Spark视图引擎），并具有最好的明文 – > C＃翻译和执行引擎。
此外，它比任何其他解决scheme都多100％。
缺点 ：StorEvil不完全支持其他人类语言（英语除外）。 StorEvil的Visual Studio集成还不如其他工具。 如果你不注意的话，StorEvil会把冰箱里的所有啤酒都喝下去。
我从理查德了解到，他打算停止Cuke4Nuke，并支持将一些Cuk4Nukefunction移入SpecFlow。 所以现在清楚的答案是SpecFlow。
我从Cuke4Nuke开始，但后来叛逃SpecFlow（抱歉理查;-)
我做这个转变的主要原因是：
- SpecFlow有很好的VS2010集成function的语法高亮。 有一个Cuke4VS项目提供类似的，但它没有VS2010的支持（或不，当我上次看，无论如何，这是相当新的）
- 我发现在SpecFlow中的debuggingtesting更容易（不要问我详细说明，这似乎是这样的… 😉
- Cuke4Nuke需要Ruby。 我确定，但是我知道的大多数C＃开发人员都会被任何非MS产品吓倒，特别是Ruby。
在Cucumber / Cuke4Nuke世界中，Specflow /我喜欢的东西有一些问题：
- Specflow的文档是相当“精简的” – 你将不得不做好准备，努力从黄瓜来源收集信息，并且直观一点他们如何应用于Specflow。 这就是说，我自己和其他几个人都在devise加强文件，以便在未来几个月内可以改进。
- 我更喜欢在命令行上运行Cucumber / Cuke4Nuketesting的经验，根据状态输出场景的颜色（我知道上面的人认为这是一个负面的，所以我想这取决于你是否是命令行帅哥……）
- 黄瓜社区更大，有更多的活动，似乎（可能）转化为更多的人在那里帮助你。
总而言之，这两方面都有改进我们编写软件的方式的潜力。
