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