演化架构与紧急设计: 测试驱动设计，第1部分 - 编程入门网

这段代码正确地报告了完全数，但是由于反向测试的原因，代码运行得非常慢 ，因为我需要检查大量数字。单元测试会引发性能问题，这使得我重新审视代码 以查看是否可以进行一些改进。目前，我把循环集中在数字本身以获得因子。但 是我必须这样做吗？如果我可以成对获得因子的话就不需要。所有因子都是成对 的（例如，如果目标数字为 28，当我找到因子 2 时，我也可以获得 14）。如果 我可以成对获得因子，那么我只需要循环到该数字的平方根。为此，我改进了算 法并将代码重构为清单 3：

清单 3. 算法的改进版本

public　class　PerfectNumberFinder2　 { 　　 public　static　boolean　isPerfect(int　number)　{ 　　　　 //　get　factors 　　　　 List<Integer>　factors　=　new　 ArrayList<Integer>(); 　　　　 factors.add(1); 　　　　 factors.add(number); 　　　　 for　(int　i　=　2;　i　<=　sqrt(number);　i++) 　　　　　　 if　(number　%　i　==　0)　{ 　　　　　　　　 factors.add(i); 　　　　　　 } 　　　　 //　sum　factors 　　　　 int　sum　=　0; 　　　　 for　(int　n　:　factors) 　　　　　　 sum　+=　n; 　　　　 //　decide　if　it''s　perfect 　　　　 return　sum　-　number　==　number; 　　 } }

这段代码运行的时间十分合理，但是几个测试断言都失败了。结果是当您成对 地获得数字时，您在到达整数平方根时将意外地获得两次数字。例如，对于数字 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。

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

通过 TDD 进行紧急设计

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

我需要所求数字的因子。

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

我需要把因子加起来。

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

清单 5. 测试 “数字是不是因子？”

public　class　 Classifier1Test　{ 　　 @Test　public　void　is_1_a_factor_of_10()　{ 　　　　 assertTrue(Cl

凌众科技专业提供服务器租用、服务器托管、企业邮局、虚拟主机等服务，公司网站：http://www.lingzhong.cn 为了给广大客户了解更多的技术信息，本技术文章收集来源于网络,凌众科技尊重文章作者的版权，如果有涉及你的版权有必要删除你的文章，请和我们联系。以上信息与文章正文是不可分割的一部分,如果您要转载本文章,请保留以上信息，谢谢!