重构——构筑测试体系

构筑测试体系

　　如果你想进行重构&＃xff0c;首要前提就是要拥有一个可靠的测试环境。

　　“编写优良的测试程序&＃xff0c;可以极大的提高我的编程速度&＃xff0c;即使不进行重构也是如此。”

　　1、自我测试代码&＃xff08;Self-testing Code &＃xff09;的价值

　　“Class 应该包含他们自己的测试代码。”

　　“每个Class 都有一个测试函数&＃xff0c;并用它测试自己这个 Class 。”

　　确保所有的测试都完全自动化&＃xff0c;让它们检查自己的测试结果。

　　只要写好一点功能&＃xff0c;就立即添加测试。

　　一整组&＃xff08;a suite of &＃xff09;测试就是一个强大的“臭虫”侦测器&＃xff0c;能够大大缩减查找“臭虫”所需要的时间。

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

　　构建自我测试的代码。

　　2、JUnit测试框架&＃xff08; Testing Framew &＃xff09;

　　频繁的运行测试&＃xff0c;每次编译请把测试也考虑进去&＃xff0c;每天至少执行每个测试一次。

　　单元测试和功能测试

　　“每当你接获臭虫提报&＃xff0c;请先撰写一个单元测试来揭发这只臭虫。”——如何揭发&＃xff1f;这里需要根据报告准确定位。单元测试会对此有帮助吗&＃xff1f;

　　3、添加更多的测试

　　“观察Class 该做的所有事情&＃xff0c;然后针对任何一项功能的任何一种可能失败的情况&＃xff0c;进行测试。”

　　“测试应该是一种风险驱动&＃xff08;risk driven &＃xff09;行为&＃xff0c;测试的目的是希望找出现在或未来的可能出现的错误。”

　　“测试的诀窍是&＃xff1a;测试你最担心的部分。”

　　这点和我目前的想法不大相同。我目前的想法是&＃xff0c;测试要对程序做100% 的保证&＃xff0c;所以&＃xff0c;要测试程序可能行为的每一种情况&＃xff0c;保证其正确性。按照我的想法&＃xff0c;值域的设置和访问函数也是要测试的。作者的意思是&＃xff0c;测试代码要用最低的成本&＃xff0c;获取最大的收益。这一点&＃xff0c;要我在实际的环境中进行抉择。

　　“编写不是十分完美的测试并实际运行&＃xff0c;好过对完美测试的无尽等待。”——我持怀疑态度。

　　运用测试用例前后执行的函数&＃xff1a;tearDown 和 setUp&＃xff0c;保证测试用例之间相互隔离&＃xff0c;而非相互影响。

　　做一个懒惰的程序员。

　　考虑可能出错的边界条件&＃xff0c;把测试火力集中在那儿。

　　“测试&＃xff08;优先&＃xff09;可以调高编程速度”&＃xff0c;这一点我要在实践中验证一下&＃xff0c;如果真是这样&＃xff0c;那我就要尝试在我们部门推行这种方法。

　　“当测试达到一定的程度后&＃xff0c;测试效益会呈现递减态势。”所以&＃xff0c;你不要期望通过测试找出所有的bug &＃xff0c;而是要通过测试&＃xff0c;找出绝大多数的 bug 。

　　这个地方其实也符合“二八定律”&＃xff1a;即20% 的测试可以找出 80% 的 bug&＃xff0c;其余的 80% 的测试可以找出剩下的 20% 的 bug 。我们要做的&＃xff0c;就是写这 20% 的测试&＃xff0c;而非 100% 的测试。