演化架构与紧急设计: 测试驱动设计,第2部分 - 编程入门网
演化架构与紧急设计: 测试驱动设计,第2部分时间:2011-05-18 IBM Neal Ford本文是分两部分的文章的第二部分,讨论如何使用 TDD 在编写代码之前编写 测试,并通过这个过程形成更好的设计。在 第 1 部分 中,我采用后测试开发方 法(在编写代码之后编写测试)编写了完全数查找程序的一个版本。然后,使用 TDD(在编写代码之前编写测试,这样就可以用测试驱动代码的设计)编写了另一 个版本。在第 1 部分的末尾,我发现我在用来保存完全数列表的数据结构类型方 面犯了一个根本性错误:我最初根据直觉选用了 ArrayList,但是后来发现 Set 更合适。我将以这个问题为起点,讨论如何改进测试的质量和检查最终代码的质 量。 测试质量 使用更好的 Set 抽象的测试见清单 1: 清单 1. 使用更好的 Set 抽象的单元测试
这段代码测试我的问题领域中最关键的部分之一:获取数字的因子。我希望彻 底地测试这个步骤,因为它是问题中最复杂的部分,所以也是最容易出现错误的 。但是,它包含一个笨重的构造:new HashSet(Arrays.asList(1, 2, 3, 6));。 即使有了现代 IDE 支持,这行代码编写起来也很别扭:输入 new,输入 Has,执 行代码探察;输入 <Int,再次执行代码探察,真是太麻烦了。我要让它容易 些。 潮湿的测试 Andy Hunt 和 Dave Thomas 所著的 The Pragmatic Programmer提出了许多良 好的编程实践,其中之一是 DRY(Don''t Repeat Yourself,不要重复自己)原则 。这条原则主张从代码中消除所有重复,因为重复常常会导致错误。但是,DRY 不适用于单元测试。单元测试常常需要测试有细微差异的代码行为,因此涉及到 相似和重复的情况。例如,为了在不同的测试中测试各种情况,常常需要复制粘 贴代码,以得出 清单 1 中预期的结果 (new HashSet(Arrays.asList(1, 2, 3, 6)))。 对于 TDD,我的经验规则是测试应该是潮湿的,但是不要湿透。也就是说,测 试中可以有一些重复(而且这是不可避免的),但是不应该创建笨拙的重复结构 。因此,我要重构测试,提供一个 private 辅助方法,用它处理这个常用的创建 语句,见清单 2: 清单 2. 保持测试适当潮湿的辅助方法
演化架构与紧急设计: 测试驱动设计,第2部分(2)时间:2011-05-18 IBM Neal Ford清单 2 中的代码能够让对因子的所有测试更加简洁,清单 1 中的测试可以改 写为清单 3 这样: 清单 3. 更潮湿的数字因子测试
在编写测试时,也应该遵守良好的设计原则。测试也是代码,良好的原则也适 用于测试(尽管原则有所差异)。 边界条件 在为一些新功能编写第一个测试时,TDD 鼓励开发人员编写失败的测试。这可 以防止测试意外地通过所有情况,也就是说,测试实际上没有测试任何东西(同 义反复 测试)。测试还可以检查您认为正确,但是没有经过充分测试的行为。这 些测试不一定需要首先采用失败测试的形式(但是,如果在认为测试应该通过时 测 |
凌众科技专业提供服务器租用、服务器托管、企业邮局、虚拟主机等服务,公司网站:http://www.lingzhong.cn 为了给广大客户了解更多的技术信息,本技术文章收集来源于网络,凌众科技尊重文章作者的版权,如果有涉及你的版权有必要删除你的文章,请和我们联系。以上信息与文章正文是不可分割的一部分,如果您要转载本文章,请保留以上信息,谢谢! |