1.1 单元测试核心原则

---

单元测试核心原则

单元测试是软件质量保障的第一道防线，其核心目标是通过最小粒度的测试验证代码逻辑的正确性。以下是编写高质量单元测试必须遵循的六大原则，结合Mockito的应用场景进行解析：

---

1. 快速反馈（Fast）

• 原则定义：单元测试应毫秒级完成（通常单个测试 < 50ms），保证开发过程中频繁运行无负担。
• Mockito场景：
  • 通过Mock外部依赖（如数据库、网络请求）避免I/O等待，加速测试执行。
  • 示例：直接模拟HttpClient返回预设响应，无需真实HTTP调用。
• 违反后果：测试速度慢 → 开发者不愿频繁运行 → 缺陷发现延迟。

---

2. 独立隔离（Isolated）

• 原则定义：每个测试用例应独立运行，不依赖其他测试的状态或执行顺序。
• Mockito场景：
  • 使用@BeforeEach重置Mock对象状态，避免测试间污染。
  • 示例：两个测试都调用userService.update()，但通过Mock隔离确保互不影响。
• 反例警示：

  // 错误：静态变量导致测试间状态共享
  static User globalUser = new User(); 
  

---

3. 可重复性（Repeatable）

• 原则定义：无论何时何地运行测试，结果必须一致（不受环境、时间、外部服务影响）。
• Mockito场景：
  • 固定模拟行为：when(dao.find(any())).thenReturn(fixedUser)。
  • 对抗随机性：Mock随机数生成器返回固定值。
• 真实案例：
  某支付测试因依赖真实汇率API，汇率波动导致测试随机失败 → 用Mock返回固定汇率解决。

---

4. 自验证（Self-Validating）

• 原则定义：测试结果应通过断言自动判断，无需人工检查日志或数据库。
• Mockito结合点：
  • 验证Mock对象交互：verify(paymentService, times(1)).charge()。
  • 断言模拟返回值：assertTrue(order.isPaid())。
• 错误模式：

  // 错误：仅打印结果，无自动化断言
  System.out.println(result); 
  

---

5. 及时性（Timely）

• 原则定义：测试代码应与生产代码同步编写（理想情况：测试先行，如TDD）。
• Mockito作用：
  • 在依赖未实现时，通过Mock接口提前编写测试。
  • 示例：前端开发依赖的API未完成 → 用Mock模拟后端响应。
• 数据支撑：
  业界统计表明，编码同时写测试的缺陷修复成本是上线后的1/6。

---

6. 单一职责（Single Responsibility）

• 原则定义：每个测试用例只验证一个逻辑分支或场景。
• 实现技巧：
  • 使用参数化测试覆盖多输入场景：@ParameterizedTest。
  • 拆分复杂测试：一个成功Case + 多个异常Case。
• Mockito示例：

  // 正确：分两个测试验证正常和异常
  @Test void loginSuccess() { ... }
  @Test void loginFailedWhenUserNotExist() { ... }
  

---

单元测试与Mockito的关系图谱

---

常见误区与修正

误区	修正方案
“单元测试必须覆盖100%代码”	优先覆盖核心逻辑和边界条件，避免过度测试
“Mock越多越好”	仅Mock外部依赖，保留内部逻辑的真实性
“测试通过即代码正确”	确保断言充分，避免“假通过”测试

---

遵循这些原则，结合Mockito的灵活模拟能力，可构建高效、可靠的单元测试体系，为代码质量提供坚实基础。