单元测试准则
单元测试准则
- Unit tests should be：small 、fast 、automated and non-interactive（无交互）、easy to run、immediately (用例独立)。
4. 代码覆盖率
- 代码覆盖率, 检查未被执行的代码。
5. 修复失败的测试
- 提交前应保证测试通过：新用例、现有用例。
- 若定期执行的测试：用例失败，应优先解决。
6. 把测试维持在单元级别
- 单元测试： 仅测试Class。
- 工作流测试：必须单独建立和执行。
7. 有胜于无,聚少成多
简单 "测试类" 也会促使建立 "被测类" 测试骨架, 可对构建环境、单元测试环境、 执行环境、覆盖率等有效性进行检查。
8. 测试独立、无序
测试用例应独立、无序，确保测试的稳定、可靠、易维护。
9. Keep tests close to the class being tested
大部分 C++库通常是创建一个和
src目录同级的tests目录, 更容易排除测试用例。
10. 合理的命名测试用例
一个方法只测一个明确特性,并合理命名. 普遍用
test[what]，如testSaveAs()。
11. 只测公有接口
测试私有成员，会让测试变繁琐且难维护。
12. 看成是黑盒，是否满足规定的需求。
使用者的角度, 测试是否满足规定的需求. 并设法让它出问题.
13. 看成是白盒，复杂逻辑。
在最复杂的逻辑部分多花些精力测试.
14. 芝麻函数也要测试
通常建议所有重要的函数都应该被测试， setter 和 getter 应工具生成.
-
从黑盒测试的观点看, 是无法知道哪些代码是芝麻级别的.
-
芝麻函数, 也可能包含错误, 通常是 "复制粘贴" 代码的后果:
private double x_, y_; public double getY(){ return x_; // error }
15. 先关注执行覆盖率
区别对待 执行覆盖率和 实际测试覆盖率.
void setLength(double length); setLength(1.0)；//100% 的执行覆盖率，实际覆盖率小于0.001
16. 覆盖边界值
尽可能彻底的测试这些边界值, 因为它们都是主要 "疑犯"。
数字：正数、负数、0、最大值、最小值、NaN(非数字)，无穷大等
字符串：空字符串、单字符、非 ASCII 字符串、多字节字符串。
集合类型：空、第一个、最后一个。
日期： 测试 1月1号, 2月29号, 12月31号
17. 提供一个随机值生成器
边界值都覆盖后，能改善测试是生成随机参数。应该覆盖各种类型的所有取值范围.若测试过程很快, 可跑个百万次.
18. 每个特性只测一次
在测试模式下, 有时会滥用断言. 但会导致维护更困难, 需要极力避免. 仅对测试方法名指示的特性进行明确测试。
19. 使用显式断言
应该总是优先使用
assertEquals(a, b)而不是assertTrue(a == b), 因为显式断言能给出更多的测试失败信息。
20. 提供反例测试，程序正确处理异常
指刻意编写问题代码, 来验证鲁棒性和能否正确的处理错误.假设如下方法的参数如果传进去的是负数, 会立马抛出异常:
try { setLength(-1.0);//反例，throws IllegalArgumentExcepti 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); if (handle == null) return;//避免测试项中断 String handleName = handle.getName(); assertEquals(handleName, "handle-01");
26. 写测试用例重现 bug
都要写一个测试用例来重现这个
bug(即无法通过测试), 并用它作为成功fixed的检验标准.
27. 测试只能证明有错
单元测试永远无法证明代码的正确性!!
一个跑失败的测试可能表明代码有错误, 但一个跑成功的测试什么也证明不了.
单元测试最有效的使用场合：底层验证、文档化需求、回归测试
回归测试: 开发或重构代码时，不破坏已有功能的正确性.
