单元测试注意事项总结（一）

为什么80%的码农都做不了架构师？>>>   

作为一名优秀的程序员，应该知道单元测试的重要性。整个软件测试工程，单元测试是基础，做好单元测试势在必行。

小编从网络和程序员处收集了大量的单元测试注意事项，以供参考。

　  1 保持单元测试小巧， 快速

　　理论上， 任何代码 Check-in 之前都应该把所有测试套件完整的跑一遍。 所以保持测试代码轻快能减少开发迭代周期。

　　2 单元测试应该是全自动/非交互式的 

　　测试套件通常是定期执行的， 执行过程也必须是完全自动化才有意义。 输出结果需要人工检查的测试不是一个好的单元测试。

　　3 让单元测试很容易跑起来

　　对开发环境进行配置， 最好是敲一条命令或是点击一个按钮就能把单个测试用例和测试套件跑起来。

　　4 对测试进行评估

　　对执行的测试进行覆盖率分析， 以便得到精确的代码执行覆盖率， 调查哪些代码未被执行。

　　5 立即修正失败的测试

　　每个开发人员都应该保证新 Check-in 的测试用例能够跑成功， 并且当有代码 Check-in 现有测试用例也都能跑通过。 

　　6 把测试维持在单元级别

　　单元测试即类 (Class) 的测试。 一个 “测试类” 应该只对应于一个 “被测类”， 并且对 “被测类” 行为的测试环境应该是隔离 的。 必须谨慎的避免使用单元测试框架来测试整个程序的工作流， 这样的测试即低效又难维护。 工作流测试 (译注: 指跨模块/类的数据流测试) 有它 自己的地盘， 但它绝不是单元测试， 必须单独设置和执行。 

　　7 由简入繁

　　再简单的测试也远远胜过完全没有测试。 一个简单的 “测试类” 会促使建立 “被测类” 基本的测试骨架， 可以对构建环境， 单元测试环境， 执行环境以及覆盖率分析工具等有效性进行检查， 同时也确保 “被测类” 能够整合并被调用。

　　下面便是单元测试版的 Hello， world! :

1 2 3 4 5 6 7 8 9

void testDefaultConstruction()   　　{   　　Foo foo = new Foo();   　　assertNotNull(foo);   　　}

　　8 保持测试的独立性 

　　为了保证测试稳定可靠且便于维护， 测试用例之间决不能有相互依赖， 也不能依赖执行的先后次序。 

　　9 测试类的控制 

　　大部分C++和 Python 库均把测试代码从功能代码目录中独立出来， 通常是创建一个和 src 目录同级的 tests 目录， 被测 模块/类名之前也常常 不加 Test 前缀。 这么做保证功能代码和测试代码隔离， 目录结构清晰， 并且发布源码的时候更容易排除测试用例。

　　10 合理的命名测试用例 

　　确保每个测试方法只测试 “被测类” 的一个明确特性， 并且相应的给测试方法命名。 典型的命名俗定是 test[what]， 比如 testSaveAs()，testAddListener()， testDeleteProperty() 等。

单元测试注意事项总结（二）

转载于:https://my.oschina.net/evget/blog/209176