演化架构与紧急设计: 测试驱动设计，第 2 部分

传统的 “预先做大量的设计（big design up front）” 需求收集过程就像是 “有损压缩”，它不能完全准确地反映应用程序所需的功能。业务分析师不可能预见到可能出现的所有问题，所以要由开发人员补充细节。开发人员在这方面表现很差，这导致在需求的定义者和实现者之间争吵不断。

敏捷的过程把 “解压” 过程尽可能延后，让开发人员身边总是有人可以回答 “程序实际上应该做什么” 这个问题，从而缓解需求收集过程中的损失。没有细节，就不可能进行设计，所以无论采用什么设计方法，必须以可行的方法补充在需求收集和定义过程中损失的细节。

测试边界条件会迫使开发人员明确考虑自己的假设。在编写解决方案时，很容易做出无效的假设。实际上，这正是传统的需求收集过程的缺点之一 — 无法收集足够的细节，所以无法消除不可避免的实现问题。需求收集是一种 有损压缩。

因为在定义 “软件必须做什么” 的过程中忽略了太多细节，所以必须通过某些机制帮助重现那些必须问的问题，从而充分地理解需求。凭空猜测业务用户实际上希望做什么是很危险的，很可能会猜错。使用测试研究边界条件有助于找到要问的问题，这对于理解需求非常重要。找到要问的问题会提供许多信息，有助于实现良好的设计。

肯定测试和否定测试

在开始研究完全数问题时，我把它分解为几个子任务。在编写测试时，我发现了另一个重要的子任务。下面是完整的列表：

我需要所求数字的因子。

我需要确定某个数字是不是因子。

我需要决定如何把因子添加到因子列表中。

我需要把因子加起来。