重构_改善既有代码的设计（四）

如果你想进行重构，首先前提就是拥有一个可靠的测试环境。编写优良的测试程序，可以极大提到我的编程速度，即使不进行重构也一样如此。这让我很吃惊，也违反许多程序员的直觉，所以我有必要解释一下这个现象。

1、自测试代码的价值

如果认真观察程序员把最多时间耗在哪里，你就会发现，编写代码其实只占非常小的一部分。有些时间用来决定下一步干什么，另一些时间花在设计上，最多的时间则是用来调试。修复错误通常是比较快的，但找出错误却是噩梦一场。当你修好一个错误，总是会有另一个错误出现，而且肯定要很久以后才会注意到它。那是你又要花上大把时间去寻找它。

每个类都应该有一个测试函数，并以它来测试自己这个类。我每次编译之后都进行测试。很快我发现自己的生产性能大大提高。我意识到那是因为我没有花太多时间去测试。如果我不小心引入一个可被现有测试捕捉到的错误，那么只要执行测试，它就会向我报告这个错误。由于测试本来是可以正常运行的，所以我知道这个错误必定是在前一次执行测试后引入的。由于我频繁地进行测试，每次测试都在不久之前，因此我知道错误的源头就是我刚刚写下的代码。而由于我对那段代码记忆犹新，份量也很小，所以就能轻松找到错误。

当然，说服别人也这么做并不容易。编写测试程序，意味要写很多额外代码。除非你确切体验到这种方法对编程速度的提升，否则自我测试就显不出它的意义。很多人根本没学过如何编写测试程序，甚至根本没考虑过测试，这对于编写自我测试代码也很不利。如果需要手动运行测试，那更是令人烦闷；但如果可以自动运行，编写测试代码就真的很有趣。

一套测试就是一个强大的bug侦测器，能够大大缩减查找bug所需要的时间。

实际上，撰写测试代码的最有用时机是在开始编程之前。当你需要添加特性的时候，先写相应测试代码。听起来离经叛道，其实不然。编写测试代码其实就是在问自己：添加这个功能需要做些什么。编写测试代码还能使你把注意力集中于接口而非实现（这永远是件好事）。预先写好的测试代码也为你的工作安上一个明确的结束标志：一旦测试代码正常运行，工作就可以结束了。

频繁进行测试时极限编程的重要一环。极限编程一次容易让人联想起那些编码飞快、自由散漫的黑客，实际上极限编程者都是十分专注的测试者。他们希望尽可能快速开发软件，而且也知道测试能让他们尽可能快速地前进。

2、基本是一些单元测试的知识，一个单元测试小例子（Eclipse默认已经带有junit插件，一般应该不需要下载junit类对应的jar包），还有功能测试和单元测试的区别

3、测试应该是一种风险驱动的行为，测试的目的是希望找出现在或未来可能出现的错误。所以我不会去测试那些仅仅读或写一个字段的访问函数，因为他们太简单了，不大可能出错。这一点很重要，因为如果你撰写过多测试，结果往往测试量反而不够。测试的要诀是：测试你最担心出错的部分。这样你就能从测试工作中得到最大利益。

（1）编写未臻完美的测试并实际运行，好过对完美测试的无尽等待。

（2）考虑可能出错的边界条件，把测试火力集中在那儿。“寻找边界条件”也包括寻找特殊的、可能导致测试失败的情况。比如，对于文件相关测试，空文件是个不粗偶的边界条件。

（3）当事情被认为应该出错时，别忘了检查是否抛出了预期的异常。

对于某些比较复杂的类，可能你得话费一些时间来浏览其接口，而在此过程中你可以真正理解这个接口，而且这对于考虑错误情况和边界情况特别有帮助。

随着测试类越来越多，你可以生成另一个类，专门用来包含由其他测试类所组成的测试套件。

什么时候应该停下来？“任何测试都不能证明一个程序没有bug”。确实如此，这并不影响“测试可以提高编程速度”。当测试数量达到一定程度之后，继续增加测试带来的效益就会呈现递减态势。你应该把测试集中在可能出错的地方。观察代码，看哪儿变得复杂；观察函数，思考哪些地方可能出错。不要因为测试无法捕捉所有bug就不写测试，因为测试的确可以捕捉到大多数bug。

对象技术有个微妙处：继承和多态会让测试变得比较困难，因为将有许多种组合需要测试。如果你有3个彼此合作的抽象类，每个抽象类有3个子类，那么你总共拥有9个可供选择的类和27中组合。“花合理时间抓出大多数bug”要好过“穷尽一生抓出所有bug”。

测试代码和产品代码之间有个区别：你可以放心的赋值、编辑测试代码。处理多种组合情况以及面对多个可供选择的类时，可以新增各种条件。

这一章主要讲述如何构筑测试体系，从自测代码的价值到建立单元测试，再到添加条件进行测试。