测试代码的坏味(翻译)
上一篇 /
下一篇 2010-03-04 23:03:20
/ 个人分类：测试代码编写
测试代码的坏味
Refactoring Test Code. xp2001,Arie van Deursen..
1.神秘的客人
当测试用到外部资源，如包含测试数据的文件，这时测试不再是自包含的了。不再有足够的信息去理解这个测试的功能，测试例也很难用做说明文档。另外，使用外部资源引入了潜在的依赖。如果这些资源发生改变，如删除或修改，相关测试将失败。
2.资源乐观主义
测试代码对外部资源（如特定的目录或
数据库表）所做的存在与否及所处状态的乐观假定，都可能使得测试结果的无法确定。测试用例时而通过，时而又神奇的能不过，这种情形是你所不想要的。
3.测试运行战争
此类战争发生在：当你独自一人执行测试，它能
工作良好，但是是多个程序员一起执行时，测试就失败了。这常常是由于资源冲突造成的。
4.过于通用的运行必备
在
JUnit框架中，程序员会将每个测试执行前用到的代码写成setUp方法，这样给这些测试创造了一个运行必备。
当setUp运行必备太过通用，不同的测试用例只使用到必备中的一部分时，坏味就出现了。必备变得难以阅读和理解。更严重的是，它会使得测试运行慢很多。测试执行太长时间的危险在于测试工作开始干扰
其他编程工作，最终使得程序员不再执行测试。
5.过于热心的测试
当一个测试方法检测一个被测对象的多个方法时，就变得难以阅读与理解，也很难当作文档。也使得测试相互依赖性更强，更难维护。
6.懒惰测试
这种情况发生在当多个测试方法使用同一个必备来检查同一个方法时。这些测试常常只有放在一起才是有意义的。
7.赌轮盘似的断言
这种坏味来自于在一个测试方法中有很多没有解释的断言。当一个断言失败，你不知道到底是哪一个失败了。
8.间接测试
当一个测试类包含了测试其他被测对象时（比如它们被被测对象引用）。
9.只为测试人员
当一个产品类包含只用于测试的方法，这些方法要么是不需要、可被删除的，要么只是用于准备测试必备。如果你不想它们存在产品代码中，你可以将其移出。
10.过于敏感的相等
使用toString方法可以快速简单地写出相等的检查。一个典型方法就是计算得到实际结果，将它映射到一个string，然后将其与代码预期结果的string进行比较。然而这种测试的结果可能会依赖于请多无关的细节，如逗号、引号、空格等。当对象的toString方法改变后，测试就会失败。
11.测试代码重复
收藏
举报
TAG:
