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