在.NET项目中使用BDD规范时，为什么要同时使用SpecFlow *和* MSpec
本文关键字：SpecFlow 为什么 MSpec 范时 项目 NET BDD | 更新日期: 2023-09-27 17:55:51
我反复听到BDD爱好者主张在同一项目中同时使用SpecFlow和MSpec。
-
显然，SpecFlow 更适合由外而内/UI 测试。（例如，使用 WatiN 或类似的东西模拟鼠标点击等的 Web 测试。
-
显然，MSpec 更适合单元测试。
现在我的问题是 - 为什么要使用两个非常相似并且做几乎相同事情的框架？
为什么不改：
- 选择一个BDD框架并坚持下去。按预期将其用于由外而内/UI 测试，
- 使用已建立的单元测试框架（例如 NUnit、MSTest 等）正常编写单元测试？
我认为我们采用BDD的原因是，我们可以通过集成测试来测试外部驱动的行为。
我不明白这如何/为什么适用于单元测试。
我同意达伦的观点。总的来说，我认为这部分是文化/学习的事情。
如果你想让业务部门在你做的可执行规范上积极协作，你需要业务可读性。所以你需要一个BDD工具，比如SpecFlow。
对于单元测试，"业务"是你或团队中的其他开发人员，所以唯一的约束是你必须以其他开发人员可以理解的方式编写单元测试（例如，它不是一个完全晦涩的代码）。
因此，你是否使用NUnit，MSpec甚至SpecFlow进行单元测试应该根据你的团队感觉舒适和高效来决定。很难从外部给出任何具体建议。如果你的团队精通 NUnit 并且只是学习 BDD/SpecFlow，我会保留 NUnit 的单元测试。如果你的团队已经沉迷于给定的时间，那么尝试一些单元级BDD工具，看看你的团队最喜欢什么，这是有意义的。
就我个人而言，我会非常小心地使用基于纯文本（外部DSL）的工具（例如SpecFlow）进行单元测试，但宁愿使用流畅接口（内部DSL）的工具，例如MSpec。但我知道一些团队成功地使用 SpecFlow 进行单元测试。
认为你的问题完全有效，因为 MSpec 和 SpecFlow 并不是非常相似，而且几乎不做同样的事情。 看看并排的两人...它们看起来一点都不像，而且它们的工作方式完全不同。
我能给你的最好的建议是阅读 RSpec 书，它详细介绍了如何使用 RSpec 和 Cucumber 的组合在 Ruby 中进行测试。 本书中的许多思想都可以应用于C#和.Net中的MSpec/SpecFlow。 这是我读过的对BDD过程的最好解释。