单元测试

• 好的单元测试应该恪守 AIR 准则

  • 单元测试在线上运行时, 应该感觉像空气 (AIR) 一样, 并不存在, 但在测试品质的保障上, 的确十分要害的

  • 好的单元测试宏观上来说, 具备以下的特点:

    • 自动化(A: Automatic)
    • 独立性(I: Independent)
    • 可反复(R: Repeatable)

• 单元测试应该是全自动执行的, 并且是非交互式的

  • 测试用例通常是被定期执行的, 执行过程必须齐全自动化才有意义
  • 输入后果须要人工查看的测试不是一个好的单元测试
  • 单元测试中不准应用 System.out 来进行人的验证, 必须应用 assert 来验证

• 放弃单元测试的独立性

  • 为了保障单元测试稳固牢靠且便于保护:

    • 单元测试用例之间决不能相互调用
    • 不能依赖执行的先后秩序

• 单元测试是能够反复执行的, 不能受到外界环境的影响

  • 单元测试通常会被放到继续集成中, 每次代码有 check in 时单元测试都会被执行

    • 如果对外部环境 (网络, 服务, 中间件等) 有依赖, 容易导致集成机制不可用
  • 为了不受外界环境的影响, 要求设计代码时就把 SUT 的依赖改成注入
  • 在测试时用 spring 这样的 DI 框架注入一个本地 (内存) 实现或者 Mock 实现

• 对于单元测试, 要保障测试粒度足够小, 有助于精确定位问题, 单元测试粒度至多是类级别, 通常是办法级别的

  • 只有测试粒度小能力在出错时尽快定位到出错地位
  • 单元测试不负责查看跨类或者跨零碎的交互逻辑, 那是集成测试的畛域

• 外围业务, 外围利用, 外围模块的增量代码确保单元测试通过

  • 新增代码及时补充单元测试
  • 如果新增代码影响了原有代码, 确保及时修改

• 单元测试代码必须写在如下工程目录中 :src/test/java, 不容许写在业务代码目录下

  • 源码构建会跳过此目录, 而单元测试框架默认扫描此目录

• 单元测试的根本指标:

  • 语句覆盖率达到70%
  • 外围模块语句覆盖率和分支覆盖率都要达到100%
  • 在工程规约的利用分层中提到的 DAO 层 ,Manager层, 可重用度高的Service, 都应该进行单元测试

• 编写单元测试代码要恪守 BCDE 规定, 以确保被测试模块交付品质:

  • B: Border , 边界值测试, 包含循环边界, 非凡取值, 非凡工夫点, 数据程序等
  • C: Correct , 正确的输出, 并失去预期的后果
  • D: Design , 与设计文档相结合, 来编写单元测试
  • E: Error , 强制错误信息输出, 比方非法数据, 异样流程, 非业务容许输出, 并失去预期的后果

• 对于数据库的查问, 更新, 删除等操作:

  • 不能够假如数据库里的数据是存在的
  • 不能够间接操作数据库将数据插入进去
  • 必须应用程序插入或者导入数据的形式来筹备数据

• 和数据库相干的单元测试, 能够设定主动回滚机制, 不给数据库造成脏数据, 或者对单元测试产生的数据有明确的前后缀标识

  • 比方在 RDC 外部的单元测试中, 应用 RDC_UNIT_TEST_的前缀标识数据
• 对于不可测的代码要做必要的重构, 使代码变得可测, 防止为了达到测试要求而书写不标准的测试代码
• 在设计评审阶段, 开发人员须要和测试人员一起确定单元测试范畴, 单元测试最好笼罩所有测试用例
• 单元测试作为一种品质保障伎俩, 不要在我的项目公布后补充单元测试用例, 须要在我的项目提测前实现单元测试

• 为了更不便地进行单元测试, 业务代码须要防止以下状况:

  • 构造方法中做的事件过多
  • 存在过多的全局变量和静态方法
  • 存在过多的内部依赖

  • 存在过多的条件语句:

    • 多层条件语句倡议应用卫语句, 策略模式, 状态模式重构

• 不要对单元测试存在误会:

  • 认为单元测试是测试的事件
  • 认为单元测试代码是多余的. 零碎整体性能与各个单元部件的测试失常与否是强相干的
  • 认为单元测试代码不须要保护. 这样会导致一段时间过后, 单元测试简直处于废除的状态
  • 认为单元测试与线上故障没有辩证关系. 好的单元测试能最大限度地躲避线上故障