我正在学习使用 ASP.NET MVC 进行行为驱动开发，并且根据 Steve Sanderson 的 a post，我了解 BDD 至少可以表示以下测试类型：单个代码单元和 UI 交互。 this post 中提到了类似的东西。如果我需要单元测试和集成测试，是否需要两个不同的测试框架？
使用上下文/规范框架（如 MSpec）对存储库、控制器和服务进行单元测试。用这个测试的结果将对开发团队有用。
使用给定/何时/那么框架测试完整的行为（集成），例如带有 Watin 的 SpecFlow。此测试的结果将对我的客户有用。
到目前为止，我看到的有关使用 BDD 的视频仅限于测试实体的行为，而没有测试存储库、控制器等的行为...是否有一个示例项目，我可以在其中看到自动化单元和集成使用 BDD 方法进行测试？
【问题讨论】：
标签： asp.net-mvc bdd specflow mspec
我个人使用 SpecFlow 来构建特定于功能的测试（即“用户创建新的公司记录”），有时（但不总是）我会使用 Watin。为了测试我的存储库或服务类，我将在 NUnit 中使用单元/集成测试。集成测试适用于我需要在测试期间与数据库对话时，单元适用于我只是在被测目标对象中运行代码而无需外部交互的情况。
我会说您不需要为非 UI 测试使用 BDD 框架。如果你愿意，你可以，但对此没有硬性规定。如果你打算这样做，那么我强烈建议为你的测试创建一个以上的项目。将它们分开是一个好主意，而不是将所有测试混合到一个项目中。你可以给它们命名：
MyProject.Tests.Features
MyProject.Tests.Integration
MyProject.Tests.Unit
如果您不想使用两个 BDD 框架，您仍然可以以 BDD 方式使用 MSTest/NUnit。例如，this 博客文章描述了一个很好的命名约定，它接近 BDD，但针对 MSTest/NUnit 单元测试。当您测试存储库之类的东西时，您可以将其用于非 SpecFlow 测试。
总而言之 - 您不必在测试中使用 SpecFlow 和 MSpec，但如果您这样做了，那么我建议您使用单独的测试项目。
【讨论】：
我基本上同意 Jason 发布的内容。
您可能希望将规范分为两类，系统/集成和单元级测试。您可以使用任何框架来描述这两个类别，但请记住，纯代码方法（NUnit、MSpec 等）需要业务分析师能够编写 C#。如果您想让分析师和用户参与编写规范，SpecFlow/Gherkin 可能是一种更好的方法。由于语法和规则（Given、When、Then）很容易理解，并且从用户的角度编写规范很容易在经过少量培训后记下。这一切都是为了弥合沟通差距并让用户帮助您的团队形成您所在领域的无处不在的语言。
我建议让规范同时支持“由外而内”和“由内而外”的工作。您可以从用户/分析师/产品所有者编写的“由外而内”的 SpecFlow 规范开始，然后从“未实现”到“绿色”编写实际代码。支持该功能的代码是使用 TDD 开发的，具有更多面向技术的框架，如 MSpec（“由内而外”部分）。
这是一个使用 MSpec 进行单元测试和集成测试的存储库：https://github.com/agross/duplicatefinder。
【讨论】：