10、合理的命名测试用例
确保每个测试方法只测试 “被测类” 的一个明确特性， 并且相应的给测试方法命名。 典型的命名俗定是 test[what]， 比如 testSaveAs()， testAddListener()， testDeleteProperty() 等。
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 浮点数这个方法就必须被调用多少次， 并且要一一验证行为的正确性。 这无疑是不可能的任务。
