实施单元测试的时候， 如果没有一份经过实践证明的详细规范， 很难掌握测试的 “度”， 范围太小施展不开， 太大又侵犯 “别人的” 地盘。 上帝的归上帝， 凯撒的归凯撒， 给单元测试念念紧箍咒不见得是件坏事， 反而更有利于发挥单元测试的威力， 为代码重构和提高代码质量提供动力。
这份文档来自 Geotechnical， 是一份非常难得的经验准则。 你完全可以以这份准则作为模板， 结合所在团队的经验， 整理出一份内部单元测试准则。
译文由强大的 reStructuredText 文本标记语法驱动。
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。
