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