1. 什么是单元测试
通常来说单元测试，是一种自动化测试，同时包含一下特性：
- 验证很小的一段代码（业务意义 或者 代码逻辑 上不可再分割的单元），能够更准确的定位到问题代码的位置
- 能够快速运行（单元测试的意义，在于快速且周期性的验证原有代码的准确性），提高项目开发效率
- 以隔离的方式 (isolated manner)运行（对外部依赖通过插桩解耦，避免单元测试的复杂度，实现问题快速定位，简化单元测试的运行环境，多个单元测试可以以任何顺序甚至并行进行）
2. 为什么要单元测试
因为单元测试有如下优点：
- 能快速的回归，提高自测的效率
- 集成测试或者端到端的手工测试效率低，而且无法覆盖到更细节的逻辑分支
- 也存在功能设计超前于产品设计，通过接口维度，无法触达某些逻辑分支，需要通过单元测试来覆盖
- 功能开发人员更了解代码的实现，开发人员写出的测试用例往往能更全面的覆盖代码
- 有良好单测的代码，往往更方便重构
- 单元测试是项目代码的一部分，维护方便，当然这也依赖良好的单元测试编写习惯，合适的颗粒度
3. 如何识别有测试价值的代码？
当我们考虑给代码添加 单元测试时，需要首先考虑加入单测后能够带来的收益有多少，以及其付出的成本有多少，用最小的维护成本提供最高的价值的单元测试
3.1 项目属性
软件本身发布更新成本比较大，如嵌入式软件，客户端程序；或者 软件的缺陷 更可能带来较大的资损，如工厂，银行内部的软件，这类软件都是需要优先考虑单元测试。
如果一个项目本身不是特别核心的项目，影响面小，迭代更新相对较容易，那么对单元测试的要求，或者说对质量的要求，也就没有那么强烈
3.2 代码属性
3.2.1 重要的代码
- 领域层
- 基础设施代码
3.2.2 不容易被集成测试覆盖的代码 - 边界条件
- 异常条件
- 低概率场景
3.2.3 容易出现问题的代码 - 复杂的业务逻辑分支
- 状态机
- 胶水代码：负责组合多个功能，多个功能的输入具有不确定性
3.3 个人不建议的单元测试的行为
- 通常来说不建议在单元测试的时候，启动spring容器后，会牵扯过多的外部依赖，导致单元测试难以进行，或者成本过高
- 同样，外部接口，数据库依赖，中间件依赖，都不建议在单元测试中加载，可以通过mock或者sub的方式来进行隔离