1、为什么要单元测试
单元测试是工程交付前质量保障的第一环，也是软件工程质量保障的重要基石，有效的单元测试能够提前发现90%以上的代码Bug问题，同时也能防止代码的腐化，在工程重构演进时起到至关重要的作用。
2、单元测试测什么
单元测试是指对软件中最小的可测单元进行检查和验证，调用被测服务的方法，根据方法的参数传入对应的数据，得到一个返回结果，最终断言返回的结果是否符合预期。
单元测试有如下几个特点：
- 单元测试是检测一小段代码的良好实践，也是测试中的最小单元。单元自测关注的是function内部的代码实现逻辑。
- 单元测试能够更加针对细节，可以很容易的发现和定位问题。单元测试也能发现代码结构的不合理性，通常来说代码结构越合理，单元测试编写就越方便。
- 典型的单元测试是测试独立的function，要尽量保证这个测试是单独孤立的。建议只对自己开发的业务类进行单元测试，并且对于外部的资源依赖（比如网络接口或者第三方组件）使用mock的方式实现，避免单元测试过慢。
- 单元测试是否依赖数据库《Unit Testing : Principles, Practices, and Patterns》个人倾向经典派
3、单元测试与集成测试
集成测试关注的是各个系统模块集成在一起时是否能正确运行，需要集成各个代码块，也需要集成外部的依赖环境。集成测试由于需要集成多个模块和外部依赖环境，比如需要配置数据或者访问外部系统，所以集成测试的开发复杂度会更复杂一些，运行起来也会比较慢。集成测试和单元测试有一个很大的不同：单元测试是不依靠于其他组件的，只测试某段代码。
如下图所示，理想的自动化测试金字塔会把单元测试当作整个金字塔的基石。因为单元测试的隔离性较强，能够快速发现和定位问题，能够在CI/CD流程中快速得到反馈，并且单元测试的复杂度较低，所以能得到更高的投入产出比。实际开发场景中，往往会对核心代码模块做充分的单元测试，然后对系统主流程做集成测试便于回归测试以及提高整体的系统覆盖率。
4、好的单元测试准则
4.1、快速原则(FIRST - Fast)
单元测试要求是可以快速运行的。在持续交付的流程中往往会在打包时自动执行单元测试，单元测试如果运行慢，则会影响整个CI/CD流程。
4.2、独立原则(FIRST - Isolated)
- 不同的测试用例之间是隔离的，每一个单元测试方法只关注逻辑的一个方面，这样有利于排错。
- 每个测试之间不应该产生依赖，不会因测试顺序不同而导致运行结果不同。
- 测试用例之间不共享状态，如果有需要相同的初始化配置，可放在setup方法里面。
- 测试时不要依赖数据库或网络接口等外部环境，可使用mock方式隔离外部的调用。单元测试通常会被放到持续集成中，每次有代码 check in 时单元测试都会被执行。如果单测对外部环境有依赖，容易导致持续集成机制的不可用。
4.3、可重复原则(FIRST - Repeatable)
单元测试要求可以稳定重复的运行，并且每次运行的结果都是相同的。
4.3、自我验证原则(FIRST - Self-verifying)
单元测试应该是全自动执行的，并且非交互式的。测试用例通常是被定期执行的，执行过程必须完全自动化才有意义。单元测试中不准使用 System.out来进行人肉验证，必须使用 assert 来验证。
4.4、及时原则(FIRST - Timely)
单元测试必须及时的进行编写，更新和维护，以保证用例可以随着业务代码的变化动态的保障质量。一般要求在编写完功能代码时就及时编写单元自测，以便及时发现bug。
4.5、单元测试编写细则
- BCDE原则：Border，边界值测试，包括循环边界、特殊取值、特殊时间点、数据顺序等；Correct，正确的输入，并得到预期的结果；Design，与设计文档相结合，来编写单元测试；Error，强制错误信息输入（如：非法数据、异常流程、非业务允许输入等），并得到预期的结果。
- 目录规范：单元测试代码必须写在指定的工程目录。比如Java工程写在src/test/java目录，不允许写在业务代码目录下。另外，集成测试的代码需要区分出单独目录。
- 命名规范：单元测试的类名与方法名要通俗易懂，最好能够让人通过方法名直观的明白该测试用例的意图。Java单元测试的类名应以XxxTest.java格式命名以便maven test命令默认能识别到。
- 不在单元测试里写异常捕捉代码，如果要测试预知的异常行为，采用ExceptException的方式。
4.5、触发单元测试的时机
- 代码提交时，保证单元测试执行及时性。执行单元测试并检测覆盖率，达到覆盖率要求才提交。
- 通过持续交付流水线pipeline来集成，如果代码单元自测覆盖率不达到要求则不允许发布dev环境。
