我学习行为驱动开发与ASP.NET MVC，并根据a post史蒂夫·桑德森明白，BDD可以说，至少，以下测试类型：代码& UI交互个别单位。在this post中提到了类似的东西。如果我想要单元测试和集成测试，我需要两个不同的测试框架吗？如何在ASP.NET MVC中以BDD风格进行单元和集成测试？
单元测试存储库，控制器，&服务使用上下文/规范框架，像MSpec。测试结果将对开发团队有用。
测试完整的行为（集成）。这个测试的结果对我的客户很有用。
到目前为止，我已经看到了使用BDD只限于测试实体的行为没有测试库，控制器等行为的视频...有一个样本项目中，我可以看到这两个使用BDD方法进行自动化单元和集成测试？
我个人使用SpecFlow构建功能的特定测试（即“用户创造了新的记录公司”），我有时会（但不总是）使用华廷。为了测试我的存储库或服务类，我将使用NUnit的单元/集成测试。集成测试适用于在测试期间需要与数据库交谈时，单元适用于仅在目标对象中运行代码而无需外部交互的情况。
我要说的是，你不需要使用BDD框架用于非UI测试。你可以，如果你想，但没有硬性规定。如果你打算这样做，那么我强烈建议为你的测试创建多个项目。保持它们分离是一个好主意，而不是将所有测试混合到一个项目中。你可以为它们命名：
MyProject.Tests.Features < - 对于BDD SpecFlow测试。
MyProject.Tests.Integration < - 对于 访问 外部资源（即数据库）的测试。
MyProject.Tests.Unit
如果你不想使用两个BDD框架，你仍然可以使用的MSTest/NUnit的一个BDD的方式。例如，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。
我同意。这是指定为场景的外部/ UI测试，因此需要SpecFlow或类似的东西。我不明白为什么单元测试应该与平常不同。 – Jonathan 2011-05-11 00:57:37