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

核心提示： 这段代码运行的时间十分合理，但是几个测试断言都失败了，演化架构与紧急设计: 测试驱动设计，第 1 部分(5)，结果是当您成对地获得数字时，您在到达整数平方根时将意外地获得两次数字，想一想最简单的事情是什么，此列表中的哪一条看上去最简单？我认为是确定数字是不是另一个数字的因子，例如，对于数字 16

这段代码运行的时间十分合理，但是几个测试断言都失败了。结果是当您成对地获得数字时，您在到达整数平方根时将意外地获得两次数字。例如，对于数字 16，平方根是 4，该数字将被意外地添加到列表中两次。通过创建一个处理这种情况的保护条件可以轻松地解决此问题，如清单 4 所示：

清单 4. 修正的改进算法
for　(int　i　=　2;　i　<=　sqrt(number);　i++)　
　　if　(number　%　i　==　0)　{　
　　　　factors.add(i);　
　　　　if　(number　/　i　!=　i)　
　　　　　　factors.add(number　/　i);　
　　}　

现在我有了后测试版本的完全数查找程序。它可以正常工作，但是一些设计问题也显现出来。首先，我使用了注释来描绘代码的各个部分。这永远是代码的一部分：希望重构为自己的方法。我刚添加的新内容可能需要使用注释说明保护条件的用途，但是我现在不管这一点。最大的问题在于其长度。我的 Java 项目的经验表明，任何方法永远不能超过 10 行代码。如果方法行数超过这个数，它几乎肯定不止做一件事，而这是不应该的。此方法明显地违背了这条经验，因此我将进行另外一种尝试，这次使用 TDD。

通过 TDD 进行紧急设计

编写 TDD 的信条是：“可以为其编写测试的最简单内容是什么？” 在本例中，是否为 “是否是一个完全数？” 不 — 这个答案过于宽泛。我必须分解问题并回想 “完全数” 的含义。我可以轻松地举出查找完全数必需的几个步骤：

我需要所求数字的因子。

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

我需要把因子加起来。

想一想最简单的事情是什么，此列表中的哪一条看上去最简单？我认为是确定数字是不是另一个数字的因子，因此这是我的第一个测试，如清单 5 所示：