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

常常被忽视的一种测试用例是边界条件：当遇到不正常的输入时，代码会做什 么？围绕 getFactors() 方法编写一些测试，可以帮助我们考虑合理和不合理的 输入可能导致什么情况。

因此，我要针对感兴趣的边界条件编写几个测试，见清单 4：

清单 4. 因子的边界条件

@Test　public　void　factors_for_100 ()　{ 　　 Classifier5　c　=　new　Classifier5(100); 　　 c.calculateFactors(); 　　 assertThat(c.getFactors(), 　　　　　　 is(expectationSetWith(1,　100,　2,　50,　4,　25,　5,　 20,　10))); } @Test(expected　=　InvalidNumberException.class) public　void　cannot_classify_negative_numbers()　{ 　　 new　Classifier5(-20); } @Test　public　void　factors_for_max_int()　{ 　　 Classifier5　c　=　new　Classifier5(Integer.MAX_VALUE); 　　 c.calculateFactors(); 　　 assertThat(c.getFactors(),　is(expectationSetWith(1,　 2147483647))); }

数字 100 看起来很有意思，因为它有许多因子。通过测试多个不同的数字， 我认识到负数对于这个问题领域是没有意义的，所以编写了一个排除负数的测试 （在我纠正它之前，这个测试确实会失败）。考虑到负数还让我想到了 MAX_INT ：如果系统的用户需要 long 数字，我的解决方案应该怎么处理呢？我原来假设 数字是整数，但是需要确保这是有效的假设。

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

需求收集是 “有损压缩”

请在身边找一张图片或画。假设这张图片包含 2 百万像素。如果把图片压缩 到只有 2,000 像素，会发生什么？它看起来还一样吗？（如果它是 Rothko 的画 ，就有可能看起来一样，但是这种情况很少见）。通过删除信息实现的压缩叫作 有损 压缩算法。如果要把压缩版本恢复为 2 百万像素，就需要填补缺失的像素 。有时候能够猜测出正确的像素，但是不总是可以。

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

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

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

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

肯定测试和否定测试

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

我需要所求数字的因子。

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

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

我需要

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