2.6. 可测试的

故事必须是可测试的。成功通过测试可以证明开发人员正确的实现了故事。如果故事不能被测试，开发人员怎么知道他们什么时候才算是完成了代码？

通常，不可测试的故事发生在一些非功能性的需求上，这些需求和软件有关，但不直接与功能有关。

例如，下面两个非功能性的故事。

• 用户必须觉得软件好用
• 用户绝不需要花很长时间等待界面出现

前面两个故事都是不可测试的。

无论什么时候，只要有可能，就要把测试自动化。 这意味着我们需要争取99%都自动化，而不是10%。

能自动化的测试基本上总是比你认为的要多。

当产品是增量开发的，很多东西变化得很快，昨天能工作的代码，今天就会出现问题。这需要自动化测试来帮助你尽早发现这些问题。

实际情况中，总有极小部分的测试是不能进行自动化测试的。比如上面的故事“用户绝不需要花很长时间等待界面出现”是不可测试的，因为它用了“绝不”，而且，“长时间等待”没有明确定义。要想演示某些东西永远不会出现时不可能的。一个更容易、更合理的目标是演示某些东西极少出现。这个故事可以改为“在95%的情况下，界面会在2秒内打开”。这样就可以测试，并且最好是写一个自动化测试来验证它。