彩票走势图

11 只测试公有接口

　　单元测试可以被定义为 通过类的公有 API 对类进行进行测试。 一些测试工具允许测试一个类的私有成员, 但这种做法应该避免, 它让测试变得繁琐而且更难维护。 如果有私有成员确实需要进行直接测试, 可以考虑把它重构到工具类的公有方法中。 但要注意这么做是为了改善设计, 而不是帮助测试。

12 看成是黑盒

　　从在第三方使用者的角度, 测试类是否满足规定的需求。 并设法让它出问题 ;(译注: 原文 tear it apart, 本意 “将它撕碎”, 我的理解是崩溃, 出问题, 不能正确工作)。 

13 看成是白盒

　　毕竟被测试类是程序员自写自测的, 应该在最复杂的逻辑部分多花些精力测试。

14 芝麻函数也要测试 

　　通常建议所有重要的函数都应该被测试到, 一些芝麻方法, 如简单的 setter 和 getter 都可以忽略。 但是仍然有充分的理由支持测试芝麻函数:

　　芝麻 很难定义。 对于不同的人有不同的理解。

　　从黑盒测试的观点看, 是无法知道哪些代码是普通的。

　　即便是再芝麻的函数, 也可能包含错误, 通常是 “复制粘贴” 代码的后果: 

　　private double weight_; 

　　private double x_, y_; 

　　public void setWeight(int weight)

　　{ 

　　weight = weight_; // error

　　}

　　public double getX() 

　　{

　　return x_;

　　}

　　public double getY()

　　{

　　return x_; // error

　　}

　　因此建议测试所有方法。 毕竟芝麻函数也容易测试。

15 先关注执行覆盖率 

　　区别对待 执行覆盖率 和 实际测试覆盖率。 测试的最初目标应该是确保较高的执行覆盖率。 这样能保证代码在 某些 参数输入时能有效执行。 一旦执行覆盖率就绪, 就应该开始改进测试覆盖率了。 注意, 实际的测试覆盖率很难衡量 (而且往往趋近于 0%)。

　　思考以下公有方法: 

　　void setLength(double length);

　　调用 setLength(1。0) 你可能会得到 100% 的执行覆盖率。 要达到 100% 的实际测试覆盖率, 有多少个 double 浮点数这个方法就必须被调用多少次, 并且要一一验证行为的正确性。 这无疑是不可能的任务。

16 覆盖边界值

　　确保参数边界值均被覆盖。 对于数字, 测试负数, 0, 正数, 最小值, 最大值, NaN (非数字), 无穷大等。 对于字符串, 测试空字符串, 单字符, 非 ASCII 字符串, 多字节字符串等。 对于集合类型, 测试空, 1, 第一个, 最后一个等。 对于日期, 测试 1月1号, 2月29号, 12月31号等。 被测试的类本身也会暗示一些特定情况下的边界值。 基本要点是尽可能彻底的测试这些边界值, 因为它们都是主要 “疑犯”。

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 每个特性只测一次

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

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