在.NET项目中使用BDD规范时，为什么要同时使用SpecFlow *和* MSpec？

Question

我反复听到BDD爱好者主张在同一个项目中使用两个 SpecFlow和MSpec。

• 显然，SpecFlow更适合于进行外部/ UI测试。 （例如，使用WatiN或类似方法模拟鼠标点击等的网络测试。）

• 显然MSpec更适合单元测试。

现在我的问题是 - 为什么要使用两个非常相似且几乎完全相同的框架？

为什么不改为：

• 选择一个BDD框架并坚持下去。按预期，将其用于进行外部/ UI测试
• 使用已建立的单元测试框架（例如NUnit，MSTest等）正常编写单元测试？

我认为我们采用BDD的原因是我们可以通过集成测试来测试外部驱动的行为。

我不知道这是如何/为什么适用于单位测试。

Answer 1

我同意达伦的观点。一般来说，我认为这部分是文化/学习的东西。

如果您希望业务主动协作您执行的可执行规范，则需要业务可读性。所以你需要一个BDD工具，比如SpecFlow。

对于单元测试，“业务”是您或团队中的其他开发人员，因此唯一的限制是您必须以其他开发人员可以理解的方式编写单元测试（例如，它不是完全模糊的码）。

因此，无论您使用NUnit，MSpec甚至是SpecFlow进行单元测试，都应根据您的团队感到舒适和高效的方式来决定。从外面提出任何具体的建议是非常困难的。如果您的团队熟练使用NUnit并且只是学习BDD / SpecFlow，我会使用NUnit进行单元测试。如果您的团队已经沉迷于当时给定的时间，那么尝试使用一些单元级别的BDD工具并了解您的团队最喜欢的内容是有意义的。

就我个人而言，我会非常小心地使用基于纯文本的（外部DSL）工具（例如SpecFlow）进行单元测试，但是宁愿选择使用流畅接口（内部DSL）的工具，比如MSpec。但我知道使用SpecFlow成功进行单元测试的团队。

Answer 2

我不认为你的问题是完全有效的，因为MSpec和SpecFlow不是非常相似，并且几乎不做同样的事情。只要看看两个并排......它们看起来没什么相似，而且它们完全不同。

我能给你的最好建议是阅读The RSpec Book，其中详细说明了如何使用RSpec和Cucumber的组合在Ruby中进行测试。本书中的许多想法都可以应用于C＃和.Net中的MSpec / SpecFlow。这是我读过的关于BDD过程的最佳解释。