JUnit 与 Mockito：把业务规则写成有意义的单元测试

有用的测试应该能抓住业务错误，而不是照抄实现。例如预留库存：数量必须为正，同一商品重复出现要合并数量，库存不够时必须拒绝且不能扣减。先写出这些输入、结果和不能发生的副作用，再写测试和实现。若测试只把代码逻辑换一种写法重述，可能连原来的错误也一起复制。

JUnit 负责发现和运行测试，并提供断言；Mockito 负责制作可控制行为的替身。JUnit Jupiter 的 @Test 标记测试，assertEquals 比较结果，assertThrows 检查异常；Mockito 的 when 设定依赖会怎样回答，verify 核对关键调用。但模拟对象说成功，只证明这次设定下业务如何处理，不证明真实 SQL、事务或网络调用成功。

测试中替代真实依赖的对象统称测试替身，但用法不同。Stub 直接给预设答案，例如固定返回“库存不足”；fake 提供一个简化但能工作的实现，例如内存仓库；spy 基于真实对象创建，没有替换掉的行为可能执行真实方法。按需要选最简单的方式：纯计算直接测试，不必模拟；需要确认非法请求绝不访问网关时，再用 mock 检查有没有发生这次调用。

将用例写成准备、执行、断言三部分。准备只构造本用例必要状态，执行聚焦一个业务动作，断言覆盖结果与相关副作用。对于数量零，既要 assertThrows(IllegalArgumentException.class, ...)，也要核对库存网关没有被调用，因为仅仅最终抛异常可能发生在已经扣库存之后。

JUnit 5.12.2 的 assertThrows 接受预期类型的子类，而 assertThrowsExactly 要求精确类型；返回的异常可以继续用于检查业务错误码和原因。不要把被测方法调用放到断言之外再包一个空 lambda，否则实际失败路径没有被测试。异常消息只有在它属于稳定契约时才精确比较，避免标点调整导致大量无意义失败。

Mockito 可用 mock(StockGateway.class) 构造依赖，通过 when(stock.reserve(...)).thenReturn(false) 模拟不足，再 verifyNoInteractions 或 verify 约束关键行为。

匹配器要遵守 API 的组合规则；spy 的 when 调用可能先执行真实方法，必要时使用适合替身语义的 doReturn 方式。不要把服务内部每个私有步骤都变成模拟点，否则实现重构会使测试脆弱。

Java 17 项目可在构建文件中固定 junit-jupiter 与 mockito-core 的测试依赖，并配置能发现 Jupiter 的测试运行器。通过 Maven 时检查 mvn test 的实际测试数量，零测试且命令成功不代表验证了行为。完整算法先用不依赖框架的 main 自测表达相同业务契约，迁移到 JUnit 时把每个场景拆为独立命名的方法即可。

JUnit r5.12.2 的 AssertThrows 执行 Executable，捕获实际异常，再用 expectedType.isInstance 判断是否属于预期类型，匹配时返回这个异常。因此子类也会被接受；若只断言 RuntimeException，意外的 NullPointerException 也可能让测试通过，要选择足够准确的预期。

异常类型不匹配时，真实实现通过 AssertionFailureBuilder 构造带预期、实际与原因的失败信息，并处理不可恢复异常；完全不抛异常则形成另一种失败。保留 cause 让报告能够指向被测行为，而不是只看到一条泛泛的类型错误。测试失败信息本身也是排障接口，需要明确而稳定。

教学模型是原创的局部断言器，不是原样 JUnit 源码，省略消息供应器、报告格式、平台工具和完整不可恢复错误策略。它只用于说明三条关键路径：匹配、类型不符、没有抛出。实际项目应使用成熟断言库，不应为了运行一个示例而替换项目测试基础设施。

读取断言实现也能发现测试设计问题：若 lambda 同时做数据准备、网关调用和结果解析，任何一步抛出符合类型的异常都可能让测试通过。应尽量把准备放在断言外，让被断言动作只包含希望验证的业务入口，并继续检查状态确实没有发生不该有的变化。

正数量的商品行先聚合为每商品需求，再一次调用网关；非法输入和总量溢出不得调用网关。内存 fake 模拟整批足够才扣减的契约，完整 Java17 程序含明确自测。

逐行调用库存网关会让早期合法行先产生副作用，直到后项非法时才报错。算法先在内存中验证全部行并聚合需求，使用 addExact 检查同商品数量总和是否溢出，然后只调用一次网关。计划构建和外部执行之间形成清晰可测试的边界。

网关契约要求整批不足时不扣减，fake 先检查所有商品，再统一扣除，供本地测试验证服务逻辑。真实数据库实现必须用自己的事务、锁或条件更新满足同样约定；内存 fake 通过不能证明真实实现拥有并发原子性。服务也不能仅靠一次方法调用就自动获得该保证。

测试分别观察结果、调用次数和剩余库存。非法数量与聚合溢出应在零调用时失败；库存不足调用一次但状态不变；重复商品成功只消耗聚合后的总量；空批按契约直接成功且无需访问网关。这样每个测试都覆盖一个容易发生行为分歧的边界。

每行处理一次，fake 对 k 项检查与扣减各一次；真实网关成本需另加。

单元测试应当快速、确定且表达业务意图。时间、随机数和外部网络可以通过明确接口注入，固定输入后便于重放失败；这不意味着把所有类都接口化，而是识别真正导致不确定性的边界。测试命名描述条件和结果，失败报告才能直接帮助定位，而不是只显示 test1 出错。

把每个内部调用顺序都 verify 一遍，会让实现很难调整。只有顺序会影响业务正确性时才重点检查，例如校验必须先于扣款。可见结果、保存状态和禁止发生的动作通常更稳定。实现改动后测试失败，要分清是业务约定变了，还是测试绑得过细，不能只为通过就删断言。

测试分层依赖要证明的事实：纯规则用单元测试，JSON 绑定与请求过滤需要对应 Web 测试，SQL、唯一约束和事务交错要靠隔离数据库验证。覆盖率可以指出未执行区域，却不证明断言足够强。可通过有意识地改变一个比较符或移除校验，检查用例是否会失败，评估测试对关键错误的敏感度。