单元测试的基本准则.pdfVIP

单元测试的基本准则 实施单元测试的时候, 如果没有一份经过实践证明的详细规范, 很难掌握测试的 “度”, 范围太 施展不开, 太大又侵犯 “别人的” 地盘. 上帝的归上帝, 凯撒的归凯撒, 给单元测试念念紧箍咒不见得 是件坏事, 反而更有利于发挥单元测试的威力, 为代码重构和提高代码质量提供动力. 这份文档来自 Geot echnical, 是一份非常难得的经验准则. 你完全可以以这份准则作为模板, 结合所在团队的经验, 整理出一份内部单元测试准则. 1. 保持单元测试小巧, 快速 理论上, 任何代码提交前都应该完整跑一遍所有测试套件. 保持测试代码执行快能够缩短迭代 开发周期. 2. 单元测试应该是全自动/非交互式的 测试套件通常是定期执行的, 执行过程必须完全自动化才有意义. 输出结果需要人工检查的测 试不是一个好的单元测试. 3. 让单元测试很容易跑起 对开发环境进行配置, 最好是敲一条命令或是点击一个按钮就能把单个测试用例或测试套件 跑起来. 4 . 对测试进行评估 对执行的测试进行覆盖率分析, 得到精确的代码执行覆盖率, 并调查哪些代码未被执行. 5. 立即修正失败的测试 每个开发人员在提交前都应该保证新的测试用例执行成功, 当有代码提交时, 现有测试用例也 都能跑通. 如果一个定期执行的测试用例执行失败, 整个团队应该放下手上的工作先解决这个问题. 6. 把测试维持在单元级别 单元测试即类 (Class) 的测试. 一个 “测试类” 应该只对应于一个 “被测类”, 并且 “被测类” 的行 为应该被隔离测试. 必须谨慎避免使用单元测试框架来测试整个程序的工作流, 这样的测试即低效 又难维护. 工作流测试 (译注: 指跨模块/类的数据流测试) 有它自己的地盘, 但它绝不是单元测试, 必 须单独建立和执行. 7. 由简入繁 更多精彩攻略访问 1 再简单的测试也远远胜过完全没有测试. 一个简单的 “测试类” 会促使建立 “被测类” 基本的测 试骨架, 可以对构建环境, 单元测试环境, 执行环境以及覆盖率分析工具等有效性进行检查, 同时也 可以证明 “被测类” 能够被整合和调用. 下面便是单元测试版的 Hello , wo rl ! : vo i t est Def ault Co nst ruct io n() { Foo f oo = new Foo (); assert Not Null(f oo ); } 8. 保持测试的独立性 为了保证测试稳定可靠且便于维护, 测试用例之间决不能有相互依赖, 也不能依赖执行的先后 次序. 9. Keep t est s close t o t he class being t est e [译注: 有意翻译该规则, 个人认为本条规则值得商榷, 大部分 C++, O bject ive-C和 Pyt ho n 库均 把测试代码从功能代码目录中独立出来, 通常是创建一个和 src 目录同级的 t est s 目录, 被测模块/ 类名之前也常常 不加 Test 前缀. 这么做保证功能代码和测试代码隔离, 目录结构清晰, 并且发布源 码的时候更容易排除测试用例.] If t he class t o t est is Foo t he t est class sho ul be calle FooTest (not Test Foo ) an kept in t he same package ( irect o ry) as Foo . Keeping t est classes in separat e irect o ry t rees makes t hem har er t o access an maint ain. Make sure t he buil enviro nment is co nf igure so t hat t he t est classes oesnt make it s way int o pro uct io n libraries o r execut ables. 10. 合