如何将“全栈”功能分解为验收、集成和单元测试？

Question

我是行为驱动开发的新手，我正在努力学习它。我使用 MSpec 和 Watin 进行验收测试，使用 MSpec 进行 ASP.Net MVC 4 的单元测试。我有一个简单的用户注册场景。

当用户输入用户名、密码、邮箱等并点击注册按钮时
它应该验证电子邮件地址
它应该检查用户名是否已经不存在
它应该注册用户
它应该发送一封欢迎电子邮件
它应该重定向到主页

有些我想测试的东西无法使用 Watin 进行测试，例如发送电子邮件、检查用户是否存在等。这些将是控制器测试的一部分。这是否意味着我的验收测试只会是当用户注册时他应该被重定向到主页？如何将整个过程分解为测试？

如果这些检查是在各种测试和不同级别中实现的，那么我如何获得一份 MSpec 提供的摘要报告，说明我已经实现了所有功能？我对人们如何打破这些任务以及他们如何获得集体报告等感到有些困惑。

Answer 1

首先从验收测试开始推动您的发展（由外而内）。 您需要编写以下场景：

用户尝试使用无效的电子邮件进行注册

这个很简单

用户尝试使用已经存在的登录名进行注册

为此，您需要能够将您的应用程序插入到 内存存储库（我建议使用 IoC 容器来轻松配置您的应用程序）。这样，您将首先使用您的应用程序注册一个“Bob”用户，然后看看当您尝试使用该登录名再次注册时会发生什么。所以基本上解决方案是使用 Repository Pattern，并在内存中实现而不是真正的 DB 实现。 我在这里假设您的数据库不包含任何业务逻辑，否则使用真正的数据库会更安全，这样您就可以在数据库中执行业务规则。这在遗留系统中很常见。 内存存储库的优点是您的测试将运行得更快，并且您不需要编写复杂的拆解代码。对于真正的数据库，您需要确保在每次测试之间清理数据库以确保测试独立性，并且使用数据库运行测试会慢很多。

用户注册成功

对于这个，您需要检查重定向，这很容易。对于电子邮件部分，您需要使用 Adapter 模式 将您的应用程序插入到存根上。您可以像内存队列那样实现存根，这样您就可以断言您的应用程序是否正确发送了电子邮件。

关于单元测试

如果您打算自己编写电子邮件语法验证，我建议您自行对该部分进行单元测试。

正如 Augusto 所提到的，Growing Object-Oriented Software, Guided by Tests 是学习 ATDD 和 TDD 的好书。

一般策略是始终从高级验收测试开始，以推动您的开发。模拟无法在内存中运行的外部服务或无法在本地安装或不易测试的服务。有意义时使用 TDD 进行单元测试。

Answer 2

您的单元测试将包含以下内容：

• 测试注册用户的代码在未给出用户名的情况下是否引发异常。
• 测试验证密码的代码是否有效。

基本上采用小单元代码并对其进行测试。

对于验收测试，您将其提升到一个新的水平并集成这些功能以确保它们正常工作。因此，您可以进行验收测试来检查整个注册功能：

Given I am a new user
When I complete the register user form
Then I will be redirected to the home page

Given I am a new user
When I complete the register user form
And I have not entered a valid password
Then I will be shown an error message

或者那个地区的东西。

就我个人而言，我不太喜欢编写测试用户界面的测试，因为 UI 可能会经常更改（这意味着您必须修复因这些更改而中断的测试）；另外，我觉得我通过编写单元测试和验收测试来重复工作。

但是，当涉及到您的客户时，ATDD 可以使您受益，因为您可以与他们交流您是如何测试应用程序的。向他们展示 BDD 测试（书面文本）比 public void ValidatePassword_PasswordNotValid_ExpectFalse 要容易得多。

这是您需要尝试 ATDD 以了解您是否会从中受益的场景之一。