单元测试的定义

  • 单元测试由开发人员完成，主要是针对软件源代码进行较小粒度的测试，白盒测试

  • 单元测试代码要早于源代码的开发

  • 在源代码修改后，将其提交到代码仓库前，都要执行所有的单元测试，以确保程序能够正确运行

一、单元测试的好处

  1. 使编码过程更加敏捷

  2. 提升代码质量

  3. 尽早发现缺陷

  4. 简化集成测试

  5. 提供文档帮助

  6. 易于调试

  7. 促进开发者优化代码的设计和结构

  8. 降低软件开发成本

二、单元测试的FIRST原则

  1. 快（Fast）
  • 指单元测试的执行速度应该很快，否则会降低编译，打包和部署的效率
  1. 独立，无依赖（Independent)

  • 每个单元测试之间应该彼此独立，互不干扰

  • 每个单元测试在执行前后，其环境应该完全一致

  1. 可重复(repeatable)
  • 每次执行单元测试时所产生的结果应该相同（使用内存数据库）
  1. 自我验证（self-validating）
  • 每个单元测试都应该对期望的测试结果自动进行自我验证
  1. 周密、细致、全面（thorough）
  • 应该尽可能周密，细致而又全面地覆盖源代码方法中的每一个分支

三、JUnit最佳实践

  1. 单元测试应该尽量避免操作外部资源和数据

  2. 软件编译打包的时候不要跳过单元测试

  3. 不要试图在一个单元测试方法中覆盖所有的可能性，分多个单元测试执行，不同的方法对应不同的测试条件

  4. 单元测试方法中必须包含assertion（断言）操作

  5. 单元测试方法所在的包名与源程序所在的包名应该一致

  6. 不要为了提高单元测试的数量，编写一些无意义的单元测试

  7. 对于期望的异常处理不要进行刻意的捕获并断言

  8. 不要在测试方法中捕获了异常，却什么也不做

  9. 单元测试也可以使用log的功能

  10. 使用自动化的构建工具

  11. 对源代码的单元覆盖率要达到百分之百

  12. 保持单元测试方法简洁小巧，快速执行。

  13. 单元测试应当与源代码同等重要，或比源代码还要重要。

四、测试驱动开发（Test Driven Development）

  • 敏捷的软件开发方法论，提倡在开发者开发足够多的代码之前优先编写单元测试方法，然后重构开发者编写的源代码。

1.红-绿-蓝（重构）

  • 红：指的是单元测试运行失败的状态，即在软件中开发新特性，新功能，缺陷对其进行重现时，我们需要开发新的单元测试代码。因为没有代码实现，测试代码必定是失败的，运行状态为红色

  • image-20211113174109048

    • 绿：编写源代码使失败的单元测试能够顺利通过，使其运行时为绿色
      • image-20211113174232500

  • 蓝（重构）:当所有的单元测试方法都能顺利通过执行时，将代码进行结构的调整，逻辑的优化，容错的处理，以及各种依赖关系的抽象和重构等。

2.TDD工作流程

  • image-20211113174720952

    1. 编写单元测试，验证软件是否满足新的功能需求
    2. 运行所有的单元测试，检查是否存在失败的单元测试代码
    3. 开发基本的功能代码，使单元测试能够成功执行
    4. 运行单元测试，如果失败则回到步骤3
    5. 重构代码，每次改动代码都需要运行单元测试，以确保重构代码的正确性，失败回到步骤3
    6. 重复整个流程，直到所有的测试条件都能通过验证