我是行为驱动开发的新手，我正在努力学习它。我使用 MSpec & Watin 进行验收测试，使用 MSpec 进行 ASP.Net MVC 4 的单元测试。我有一个简单的用户注册场景。
When a user enters username, password, email, etc. and clicks on register button
It should validate email address
It should check that the username already does not exist
It should register the user
It should send a welcome email
It should redirect to the home page
有些我想测试的东西不能用 Watin 测试，比如发送电子邮件、检查用户是否存在等。这些将是 Controller 测试的一部分。这是否意味着我的验收测试只会是当用户注册时他应该被重定向到主页？我如何将整个过程分解为测试？
如果这些检查是在各种测试和不同级别中实现的，那么我如何获得 MSpec 可用的总结报告，我已经实现了所有功能？我对人们如何打破这些任务以及他们如何获得集体报告等感到有些困惑。
最佳答案
先从验收测试开始 插入您的发展 (外内)。
您需要编写以下场景:
用户尝试使用无效电子邮件注册
这是一个很容易的
用户尝试使用已经存在的登录名进行注册
为此，您需要能够将您的应用程序插入 在内存存储库中 (我建议使用 IoC 容器 来轻松配置您的应用程序)。这样，您首先使用您的应用程序注册“Bob”用户，然后查看当您尝试使用该登录名再次注册时会发生什么。所以基本上解决方案是使用 存储库模式 ，并且有一个内存实现而不是你真正的数据库实现。
我在这里假设您的数据库不包含任何业务逻辑，否则使用真实数据库会更安全，以便您可以在数据库中执行业务规则。这在遗留系统中很常见。
内存存储库的优势在于您的测试将运行得更快，并且您无需编写复杂的拆卸代码。对于真正的数据库，您需要确保在每次测试之间清理数据库以确保测试独立性，并且使用数据库运行测试要慢得多。
用户注册成功
对于这个，您需要检查重定向，这很容易。对于电子邮件部分，agian，您需要使用 将您的应用程序插入 stub 。适配器模式 .您可以像 一样实现 stub 。在内存队列中 ，这样您就可以断言您的应用程序是否正确发送了电子邮件。
关于单元测试
如果您打算自己编写电子邮件语法验证，我建议您自己对该部分进行单元测试。
正如奥古斯托所说，Growing Object-Oriented Software, Guided by Tests是学习 ATDD 和 TDD 的好书。
一般策略是始终从高级验收测试开始，以插入您的开发。模拟无法在内存中运行的外部服务或无法在本地安装或不易测试的服务。在有意义的情况下使用 TDD 进行单元测试。
关于unit-testing - 如何将 "full stack"功能分解为验收、集成和单元测试？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/14099970/