我正在学习基于ASP.NET MVC的行为驱动开发 一个帖子 来自Steve Sanderson，了解BDD至少可以表示以下测试类型：代码和UI交互的单个单元。类似的东西在提到 这个帖子。如果我需要单元测试和集成测试，是否需要两个不同的测试框架？
使用上下文/规范框架（如MSpec）对存储库，控制器和服务进行单元测试。使用它进行测试的结果对开发团队很有用。
使用给定/ when / then框架测试完整行为（集成），例如使用Watin的SpecFlow。此测试的结果对我的客户非常有用。
到目前为止我使用BDD看到的视频仅限于测试实体的行为而不测试存储库，控制器等的行为......是否有一个示例项目，我可以看到自动单元和集成测试使用BDD方法？
我个人使用SpecFlow来构建特定于功能的测试（即“用户创建新的公司记录”），我有时（但不总是）使用Watin。为了测试我的存储库或服务类，我将使用NUnit的单元/集成测试。集成测试适用于我在测试期间需要与数据库进行通信的时候，单元用于在没有外部交互的情况下在测试中的目标对象中运行代码。
我会说你不需要使用BDD框架进行非UI测试。如果你愿意，你可以，但对此没有严格的规定。如果您打算这样做，那么我强烈建议您为测试创建多个项目。保持它们分离是一个好主意，而不是将所有测试混合到一个项目中。你可以命名他们：
MyProject.Tests.Features < - 对于BDD SpecFlow测试。
MyProject.Tests.Integration < - For 访问的测试 外部资源即数据库。
MyProject.Tests.Unit
如果您不想使用两个BDD框架，您仍然可以以BDD方式使用MSTest / NUnit。例如， 这个 博客文章描述了一个很好的命名约定，它接近BDD，但针对的是MSTest / NUnit单元测试。在测试存储库之类的东西时，可以将它用于非SpecFlow测试。
总而言之 - 您不必在测试中使用SpecFlow和MSpec，但如果您这样做，那么我建议单独的测试项目。
我个人使用SpecFlow来构建特定于功能的测试（即“用户创建新的公司记录”），我有时（但不总是）使用Watin。为了测试我的存储库或服务类，我将使用NUnit的单元/集成测试。集成测试适用于我在测试期间需要与数据库进行通信的时候，单元用于在没有外部交互的情况下在测试中的目标对象中运行代码。
我会说你不需要使用BDD框架进行非UI测试。如果你愿意，你可以，但对此没有严格的规定。如果您打算这样做，那么我强烈建议您为测试创建多个项目。保持它们分离是一个好主意，而不是将所有测试混合到一个项目中。你可以命名他们：
MyProject.Tests.Features < - 对于BDD SpecFlow测试。
MyProject.Tests.Integration < - For 访问的测试 外部资源即数据库。
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。