6. 用户故事验收测试

ATDD

写验收测试的好处有很多，其中之一就是很多客户和开发人员讨论的很多细节可以通过验收测试记录下来。

比起写冗长的需求列表，像“系统应该...”，可以用测试来充实很多用户故事的细节。

整理验收测试是基本是两步流程：

第一，将测试要点记录在故事卡的背面，任何时候发现新的测试，都可以记录到故事卡的背面
第二，将测试要点变成全面的测试，这些测试可以用来演示故事已正确、完整的实现

比如，一个记录在故事卡背面的测试要点的例子，“公司可以用信用卡支付发布工作的费用”，这个故事卡的背面可能一下这些测试要点：

用Visa信用卡、万事达信用卡和运通卡测试。（通过）
用大莱卡测试。（失败）
用正确的、错误的和空的卡测试
用过期的信用卡测试
测试不同的交易金额（包括超出信用卡额度限制）

这些测试要点记录了客户提出的一些假设。

假定在招聘网站的例子中的客户写了一个故事“求职者可以查看指定工作的详细信息”。

客户和开发人员讨论这个故事，确定一些需要显示的一些工作信息 -- 职位名称，描述，工作地点，薪水范围，如何申请等等。

然而，可以了解并不是所有公司都会提供所有这些信息，所以他希望网站能够自动处理未填的数据。

比如，没有提供薪水信息，客户甚至不希望提供“薪水范围”标签出现在屏幕上。

这应该在一个测试里反映，因为程序员可能会假定系统发布工作模块要求所有工作都提供薪水信息。

验收测试也提供了确认故事是否被完整实现的基本标准。有了这样的标准，我们就知道什么时候某件事算是做完了，这是避免了花太多或太少的时间和精力的最好方法。

举个生活的例子，我妻子烤蛋糕时，她的验收标准就是在蛋糕里插一根牙签。如果牙签拿出来是赶紧的，那么蛋糕就算是做好了。而我则是将手指插入蛋糕，然后尝尝，以此来验收测试她做的蛋糕。

6.1. 在写代码之前写测试

在开始编写故事代码之前，验收测试可以为程序员提供大量有用的信息。

例如，想想“测试不同交易金额（包括超过信用卡额度限制）”。

如果在程序员开始写代码前写了这个测试。它会提醒程序员处理因信用额度不够导致交易失败的情况。

如果没有看到这个测试，有些程序员就会忘记支持这种情况。

显然，为了让程序员尽早了解这些信息，应当在为这个故事编写代码前就开始制定验收测试。

一般在下面这些时候写测试。

开发人员和客户讨论故事且需要记录明确细节时
在迭代开始时，在写代码前作为一项专门的任务
在开发中或之后的任何时候发现新的测试时

理想状况下，在客户和开发人员讨论故事的时候，他们把细节都写成测试。

在迭代的开始时就要过一遍所有故事，写一些能想到的测试。比较好的做法是，考虑每个故事，然后问一些类似下面的问题。

关于这个故事，程序员要知道什么？
对于怎么实现这个故事，我的想法是什么？
有没有一些特殊情况会使用这个故事有不一样的行为？
这个故事什么情况下会出错？

下面有一个真实项目的例子，一个扫描软件的故事。

这个故事的作者清晰知道他的期望。

例如：在一个新的文档中打开新扫描的页面，即使软件已经打开了一个文档。

这个例子中，这个期望被作为故事的一部分卸载卡片的正面。我们也可以轻松的将这个期望作为卡片背面的第一个测试。重要的是，在程序员开始实现这个故事前，通过故事卡片可以了解这个期望。

否则，程序员很有可能写出不一样的软件行为，如将新扫描的页面插入到当前文档。

那如果我们有了这样清晰的期望，我们应该告诉程序员你的期望。

比如，我们可以这样描述我们的期望。