单元测试

1. 单元测试必须遵守 AIR 原则。单元测试在运行时，感觉像空气（AIR）一样并不存在，但在测试质量的保
   障上，却是非常关键的。好的单元测试宏观上来说，具有自动化、独立性、可重复执行的特点。
   • A：Automatic（自动化）
   • I：Independent（独立性）
   • R：Repeatable（可重复）
2. 单元测试应该是全自动执行的，并且非交互式的。测试框架通常是定期执行的，执行过程必须完全自动化
   才有意义。输出结果需要人工检查的测试不是一个好的单元测试。单元测试中不准使用 echo / print / dump
   等来进行人肉验证，必须使用 assert 来验证。
3. 单元测试严禁出现 dd / exit / die 等异常流程
4. 单元测试是可以重复执行的，不能受到外界环境（网络、服务、中间件等）的影响。
5. 对于单元测试，要保证测试粒度足够小，有助于精确定位问题。单测粒度至多是类级别，一般是方法级别。
6. 核心业务、核心应用、核心模块的增量代码确保单元测试通过。
7. 单元测试的基本目标：语句覆盖率达到 70%；核心模块的语句覆盖率和分支覆盖率都要达到 100%
8. 编写单元测试代码遵守 BCDE 原则，以保证被测试模块的交付质量。
   • B：Border，边界值测试，包括循环边界、特殊取值、特殊时间点、数据顺序等。
   • C：Correct，正确的输入，并得到预期的结果。
   • D：Design，与设计文档相结合，来编写单元测试。
   • E：Error，强制错误信息输入（如：非法数据、异常流程、非业务允许输入等），并得到预期的结果。
9. 对于数据库相关的查询，更新，删除等操作，不能假设数据库里的数据是存在的，或者直接操作数据库把
   数据插入进去，请使用程序插入或者导入数据的方式来准备数据。
10. 在单元测试执行完后, 应该对数据库没有任何修改, 可以使用事务回滚或标记手动删除的形式去做
11. 对于不可测的代码建议做必要的重构，使代码变得可测，避免为了达到测试要求而书写不规范测试代码。
12. 单元测试作为一种质量保障手段，不建议项目发布后补充单元测试用例，建议在项目提测前完成单元测试。