构筑测试体系
如果你想进行重构，首要前提就是要拥有一个可靠的测试环境。
“编写优良的测试程序，可以极大的提高我的编程速度，即使不进行重构也是如此。”
1、自我测试代码（Self-testing Code ）的价值
“Class 应该包含他们自己的测试代码。”
“每个Class 都有一个测试函数，并用它测试自己这个 Class 。”
确保所有的测试都完全自动化，让它们检查自己的测试结果。
只要写好一点功能，就立即添加测试。
一整组（a suite of ）测试就是一个强大的“臭虫”侦测器，能够大大缩减查找“臭虫”所需要的时间。
“实际上，编写测试代码的最有用时机是在开始编程之前。当你需要添加特性的时候，先写相应的测试代码。听起来离经叛道，其实不然。填写测试代码其实就是问自己：添加这个功能需要做什么。编写测试代码还能使你把注意力集中于接口而非实现上头（永远是件好事）。预先写好的测试代码也为你的工作按上一个明确的结束标志：一旦测试代码运行正常，工作就可以结束了。”
构建自我测试的代码。
2、JUnit测试框架（ Testing Framew ）
频繁的运行测试，每次编译请把测试也考虑进去，每天至少执行每个测试一次。
单元测试和功能测试
“每当你接获臭虫提报，请先撰写一个单元测试来揭发这只臭虫。”——如何揭发？这里需要根据报告准确定位。单元测试会对此有帮助吗？
3、添加更多的测试
“观察Class 该做的所有事情，然后针对任何一项功能的任何一种可能失败的情况，进行测试。”
“测试应该是一种风险驱动（risk driven ）行为，测试的目的是希望找出现在或未来的可能出现的错误。”
“测试的诀窍是：测试你最担心的部分。”
这点和我目前的想法不大相同。我目前的想法是，测试要对程序做100% 的保证，所以，要测试程序可能行为的每一种情况，保证其正确性。按照我的想法，值域的设置和访问函数也是要测试的。作者的意思是，测试代码要用最低的成本，获取最大的收益。这一点，要我在实际的环境中进行抉择。
“编写不是十分完美的测试并实际运行，好过对完美测试的无尽等待。”——我持怀疑态度。
运用测试用例前后执行的函数：tearDown 和 setUp，保证测试用例之间相互隔离，而非相互影响。
做一个懒惰的程序员。
考虑可能出错的边界条件，把测试火力集中在那儿。
“测试（优先）可以调高编程速度”，这一点我要在实践中验证一下，如果真是这样，那我就要尝试在我们部门推行这种方法。
“当测试达到一定的程度后，测试效益会呈现递减态势。”所以，你不要期望通过测试找出所有的bug ，而是要通过测试，找出绝大多数的 bug 。
这个地方其实也符合“二八定律”：即20% 的测试可以找出 80% 的 bug，其余的 80% 的测试可以找出剩下的 20% 的 bug 。我们要做的，就是写这 20% 的测试，而非 100% 的测试。
