单元测试准则(2)

　　17. 提供一个随机值生成器

　　当边界值都覆盖了, 另一个能进一步改善测试覆盖率的简单方法就是生成随机参数, 这样每次执行测试都会有不同的输入.

　　想要做到这点, 需要提供一个用来生成基本类型 (如: 浮点数, 整型, 字符串, 日期等) 随机值的工具类. 生成器应该覆盖各种类型的所有取值范围.

　　如果测试时间比较短, 可以考虑再裹上一层循环, 覆盖尽可能多的输入组合. 下面的例子是验证两次转换 little endian 和 big endian 字节序后是否返回原值. 由于测试过程很快, 可以让它跑上个一百万次.

　　void testByteSwapper()

　　{

　　for (int i = 0; i < 1000000; i++) {

　　double v0 = Random.getDouble();

　　double v1 = ByteSwapper.swap(v0);

　　double v2 = ByteSwapper.swap(v1);

　　assertEquals(v0, v2);

　　}

　　}

　　18. 每个特性只测一次

　　在测试模式下, 有时会情不自禁的滥用断言. 这种做法会导致维护更困难, 需要极力避免. 仅对测试方法名指示的特性进行明确测试.

　　因为对于一般性代码而言, 保证测试代码尽可能少是一个重要目标.

　　19. 使用显式断言

　　应该总是优先使用 assertEquals(a, b) 而不是 assertTrue(a == b), 因为前者会给出为何导致测试失败的更有意义的信息. 在事先不确定输入值的情况下, 这条规则尤为重要, 比如之前使用随机参数值组合的例子.

　　20. 提供反向测试

　　反向测试是指刻意编写问题代码, 来验证鲁棒性和能否正确的处理错误.

　　假设如下方法的参数如果传进去的是负数, 会立马抛出异常:

　　void setLength(double length) throws IllegalArgumentExcepti

　　可以用下面的方法来测试这个特例是否被正确处理:

　　try {

　　set Length(-1.0);

　　fail(); // If we get here, something went wrong

　　}

　　catch (IllegalArgumentException exception) {

　　// If we get here, all is fine

　　}

　　21. 代码设计时谨记测试

　　编写和维护单元测试的代价是很高的, 减少代码中的公有接口和循环复杂度是降低成本, 使高覆盖率测试代码更易于编写和维护的有效方法.

　　一些建议:

　　使类成员常量化, 在构造函数中进行初始化. 减少 setter 方法的数量.

　　限制过度使用继承和公有虚函数.

　　通过使用友元类 (C++) 或包作用域 (Java) 来减少公有接口.

　　避免不必要的逻辑分支.

　　在逻辑分支中编写尽可能少的代码.

　　在公有和私有接口中尽量多用异常和断言验证参数参数的有效性.

　　限制使用快捷函数. 对于黑箱而言, 所有方法都必须一视同仁的进行测试. 考虑以下简短的例子:

　　public void scale(double x0, double y0, double scaleFactor)

　　{

　　// scaling logic

　　}

　　public void scale(double x0, double y0)

　　{

　　scale(x0, y0, 1.0);

　　}

　　删除后者可以简化测试, 但用户代码的工作量也将略微增加.

　　22. 不要访问预定的外部资源

　　单元测试代码不应该假定外部的执行环境, 以便在任何时候/任何地方都能执行. 为了向测试提供必需的资源, 这些资源应该由测试本身提供.

　　比如一个解析某类型文件的类, 可以把文件内容嵌入到测试代码里, 在测试的时候写入到临时文件, 测试结束再删除, 而不是从预定的地址直接读取.

　　23. 权衡测试成本

　　不写单元测试的代价很高, 但是写单元测试的代价同样很高. 要在这两者之间做适当的权衡, 如果用执行覆盖率来衡量, 业界标准通常在 80% 左右.

　　很典型的, 读写外部资源的错误处理和异常处理就很难达到百分百的执行覆盖率. 模拟数据库在事务处理到一半时发生故障并不是办不到, 但相对于进行大范围的代码审查, 代价可能太大了.

　　24. 合理安排测试优先次序

　　单元测试是典型的自底向上过程, 如果没有足够的资源测试一个系统的所有模块, 就应该先把重点放在较底层的模块.

　　25. 为测试失败做好准备

　　考虑下面的这个例子:

　　Handle handle = manager.getHandle();

　　assertNotNull(handle);

　　String handleName = handle.getName();

　　assertEquals(handleName, "handle-01");

　　如果第一个断言失败, 紧接其后的语句会导致代码崩溃, 剩下的测试都将不被执行. 任何时候都要为测试失败做好准备, 避免单个失败的测试项中断整个测试套件的执行. 上面的例子可以重写成:

　　Handle handle = manager.getHandle();

　　assertNotNull(handle);

　　if (handle == null) return;

　　String handleName = handle.getName();

　　assertEquals(handleName, "handle-01");

　　26. 写测试用例重现 bug

　　每上报一个 bug, 都要写一个测试用例来重现这个 bug (即无法通过测试), 并用它作为成功修正代码的标准.

　　27. 了解局限

　　单元测试永远无法证明代码的正确性

　　一个跑失败的测试可能表明代码有错误, 但一个跑成功的测试什么也证明不了.

　　单元测试最有效的应用场合是验证和, 以及 回归测试: 当新功能增加和代码进行重构的同时，会不会影响到旧功能的正确性.

　　参考资料

　　[1] 维基百科关于单元测试的定义: Unit Testing

　　[2] 白盒和黑盒测试的简短描述: What is black box/white box testing?

　　[3] 我们最常用的 C++ 单元测试框架: CxxTest

　　[4] 我们最常用的 Java 单元测试框架: TestNG

原文转自：http://www.wangyuxiong.com/archives/51625