单元测试准则（一）

　　1. 保持单元测试小巧， 快速理论上， 任何代码 Check-in 以前都应该把全部测试套件完整的跑一遍. 因此保持测试代码轻快能减小开发迭代周期.
 　　  2. 单元测试应该是全自动/非交互式的测试套件一般是按期执行的， 执行过程也必须是彻底自动化才有意义. 输出结果须要人工检查的测试不是一个好的单元测试.
 　　  3. 让单元测试很容易跑起来对开发环境进行配置， 最好是敲一条命令或是点击一个按钮就能把单个测试用例和测试套件跑起来.
 　　  4. 对测试进行评估对执行的测试进行覆盖率分析， 以便获得精确的代码执行覆盖率， 调查哪些代码未被执行.
 　　  5. 当即修正失败的测试每一个开发人员都应该保证新 Check-in 的测试用例可以跑成功， 而且当有代码 Check-in 现有测试用例也都能跑经过.
 　　  6. 把测试维持在单元级别单元测试即类 (Class) 的测试. 一个 "测试类" 应该只对应于一个 "被测类"， 而且对 "被测类" 行为的测试环境应该是隔离的. 必须谨慎的避免使用单元测试框架来测试整个程序的工做流， 这样的测试即低效又难维护. 工做流测试 (译注: 指跨模块/类的数据流测试) 有它本身的地盘， 但它毫不是单元测试， 必须单独设置和执行.
 　　  7. 由简入繁再简单的测试也远远赛过彻底没有测试. 一个简单的 "测试类" 会促使创建 "被测类" 基本的测试骨架， 能够对构建环境， 单元测试环境， 执行环境以及覆盖率分析工具等有效性进行检查， 同时也确保 "被测类" 可以整合并被调用.下面即是单元测试版的 Hello， world! :void testDefaultConstruction(){Foo foo = new Foo();assertNotNull(foo);}
 　　  8. 保持测试的独立性为了保证测试稳定可靠且便于维护， 测试用例之间决不能有相互依赖， 也不能依赖执行的前后次序.
 　　  9. Keep tests close to the class being tested[译注: 我未翻译该规则， 我的认为本条规则值得商榷， 大部分 C++ 和 Python 库均把测试代码从功能代码目录中独立出来， 一般是建立一个和 src 目录同级的 tests 目录， 被测模块/类名以前也经常 不加 Test 前缀. 这么作保证功能代码和测试代码隔离， 目录结构清晰， 而且发布源码的时候更容易排除测试用例.]If the class to test is Foo the test class should be called FooTest (not TestFoo) and kept in the same package (directory) as Foo. Keeping test classes in separate directory trees makes them harder to access and maintain.Make sure the build environment is configured so that the test classes doesn't make its way into production libraries or executables.
 　　  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 浮点数这个方法就必须被调用多少次， 而且要一一验证行为的正确性. 这无疑是不可能的任务.

本文转自：http://www.spasvo.com/news/html/20131224170018.html