编写原则
- 【强制】好的单元测试必须遵守AIR原则。
说明：单元测试在线上运行时，感觉像空气（AIR）一样感觉不到，但在测试质量的保障上，却是非常关键的。好的单元测试宏观上来说，具有自动化、独立性、可重复执行的特点。
⚫ A：Automatic（自动化）
⚫ I：Independent（独立性）
⚫ R：Repeatable（可重复）
-
【强制】单元测试应该是全自动执行的，并且非交互式的。测试用例通常是被定期执行的，执行过程必须完全自动化才有意义。输出结果需要人工检查的测试不是一个好的单元测试。单元测试中不准使用System.out来进行人肉验证，必须使用assert来验证。
-
【强制】保持单元测试的独立性。为了保证单元测试稳定可靠且便于维护，单元测试用例之间决不能互相调用，也不能依赖执行的先后次序。
反例：method2需要依赖method1的执行，将执行结果作为method2的输入。
- 【强制】单元测试是可以重复执行的，不能受到外界环境的影响。
说明：单元测试通常会被放到持续集成中，每次有代码check in时单元测试都会被执行。如果单测对外部环境（网络、服务、中间件等）有依赖，容易导致持续集成机制的不可用。
正例：为了不受外界环境影响，要求设计代码时就把SUT的依赖改成注入，在测试时用spring 这样的DI框架注入一个本地（内存）实现或者Mock实现。
- 【强制】对于单元测试，要保证测试粒度足够小，有助于精确定位问题。单测粒度至多是类级别，一般是方法级别。
说明：只有测试粒度小才能在出错时尽快定位到出错位置。单测不负责检查跨类或者跨系统的交互逻辑，那是集成测试的领域。
- 【强制】核心业务、核心应用、核心模块的增量代码确保单元测试通过。
说明：新增代码及时补充单元测试，如果新增代码影响了原有单元测试，请及时修正。
- 【强制】一个测试应当只检查一件事。
说明：明确测试意图，一旦出错可以精准定位问题。
- 【强制】避免条件逻辑。
说明：条件逻辑会让你的单元测试更难以维护，出问题不容易排查，不够精准。
工程规范
- 测试类文件工程目录规范
-
- 单元测试类必须放在工程目录：“src/test/java”下。
- 单元测试类文件子目录应与类文件目录保持一致。
- 测试资源文件目录规范
-
- 测试资源文件放在工程目录：“src/test/resources”下。
- 测试数据库脚本放在工程目录：“src/test/resources/db”下。
- 冗长的数据模拟代码必须放在json文件放在工程目录“src/test/resources/测试类名”下/方法名/参数或变量名称.json。比如：“src/test/resources/JobStatisticMetricServiceImplTest/testListHolidays_JobDayMapperReturnsNoItems/userCreateDTO.json”
命名规范
- 命名规则
-
- 类名：【被测类】Test，举例 JobStatisticMetricServiceImplTest
- 方法名：test【被测方法】_【被测场景】，举例 testListHolidays testListHolidays_JobDayMapperReturnsNoItems
- 变量命名：保持和开发规范一致
- 常量命名：保持和开发规范一致
测试数据规范
- 基本原则
-
- 每个人的测试数据尽量独立，数据有自己的标签。
- 不随意修改他人的测试数据、不随意修改基础数据，不随意修改自己不太了解的数据，避免对他人测试造成影响。
- 需要修改他人数据时，要提前跟他人确认。
- 需要修改基础数据时，需要评估整体影响。
- Restore测试环境数据时，需要提前周知干系人restore计划时间，确认无误后进行，不允许私下操作。
- 数据清理
-
- 功能测试的数据一般不需要清理。
- 特殊测试完成后，如果留存的数据会对其他测试造成影响，应该及时清理。
- 功能测试的数据一般不需要清理。
测试用例编写流程规范
以下用例流程基于PowerMock和Mockito框架编写，以Mockito为主、以PowerMock为辅(更多测试框架相关知识：mockito官方文档，powermock官方文档，使用强大的 Mockito 测试框架来测试你的代码，Java单元测试技巧之PowerMock)，介绍一下如何编写单元测试用例。
