本文讲解如何通过合理重构（如提取可测试方法、解耦 Lambda 执行逻辑）来对含异常处理的 forEach + Lambda 场景进行有效单元测试，确保遍历逻辑完整执行且异常不中断流程。
本文讲解如何通过合理重构（如提取可测试方法、解耦 lambda 执行逻辑）来对含异常处理的 `foreach` + lambda 场景进行有效单元测试，确保遍历逻辑完整执行且异常不中断流程。
在 Java 单元测试中，直接测试 list.forEach(...) 中的 Lambda 表达式本身是不可行的——Lambda 是匿名函数，无法被 Mockito 等框架直接拦截或验证其内部调用行为。更关键的是，你真正关心的不是 Lambda 写法是否正确，而是 myFunction() 是否能稳健地完成整个列表的遍历，即使中间某个元素触发了 checkNumber() 中的异常。
原始代码的问题在于：myFunction() 将数据准备（Arrays.asList(...)）与遍历逻辑（forEach + Lambda）强耦合，导致无法向其注入自定义测试数据（例如包含 3 的特定列表），也无法验证遍历是否真正执行了全部 6 个元素。
✅ 正确做法是面向行为重构：将核心遍历逻辑提取为独立、参数化的方法，使其可被直接调用和断言。如下所示：
public static void myFunction() {
List<Integer> list = Arrays.asList(1, 2, 3, 4, 5, 6);
checkList(list); // 委托给可测试方法
}
// ✅ 可测试的核心遍历逻辑 —— 接收任意列表，便于构造边界场景
public static void checkList(List<Integer> list) {
list.forEach(num -> checkNumber(num));
}
public static void checkNumber(Integer num) {
try {
if (num != null && num.equals(3)) {
throw new RuntimeException("3 found not to execute");
}
System.out.println("mynum:" + num);
} catch (Exception e) {
System.out.println(e.getMessage()); // 更规范的日志输出
}
}现在，你可以编写高覆盖度的 JUnit 测试：
立即学习“Java免费学习笔记（深入）”；
import org.junit.jupiter.api.Test;
import java.util.Arrays;
import java.util.List;
import static org.junit.jupiter.api.Assertions.*;
class MyFunctionTest {
@Test
void checkList_executesAllElementsEvenWhenExceptionOccurs() {
// 给定：含异常触发值 3 的列表
List<Integer> input = Arrays.asList(1, 2, 3, 4);
// 当：调用 checkList（即 myFunction 的核心逻辑）
// 注意：我们不验证 System.out（应避免在业务逻辑中依赖打印），而是关注行为结果
// 实际项目中建议将 checkNumber 的副作用（如日志）抽离为可注入的 Logger，此处为简化聚焦逻辑
// 验证：遍历未提前终止 → 元素总数应被完整处理（可通过计数器或 Spy 验证）
// 方案一：使用 CountDownLatch 或 AtomicReference 捕获执行次数（推荐用于集成验证）
// 方案二（更轻量）：重构 checkNumber 为返回状态，并在 checkList 中统计
// 这里演示“行为断言”思路：若无异常，4次执行；有异常，仍应是4次（因异常被内部捕获）
// ✅ 实际推荐：为 checkNumber 添加测试，再为 checkList 编写“执行完整性”测试
// 由于 checkNumber 内部吞掉了异常，checkList 的职责只是确保 forEach 完成 —— 这是 forEach 本身的保证（除非抛出未捕获异常）
// 因此，本测试的重点是：确认 checkList 调用后不抛异常，且逻辑按预期流转
assertDoesNotThrow(() -> checkList(input));
}
@Test
void checkNumber_handlesThreeGracefully() {
// 单独测试 checkNumber 的异常处理能力
assertDoesNotThrow(() -> checkNumber(1));
assertDoesNotThrow(() -> checkNumber(3)); // 异常被捕获，方法不抛出
assertEquals(0, System.out.toString().length()); // ⚠️ 实际中应重定向/替换 System.out 进行断言
}
}? 关键注意事项：
- 不要测试 Lambda 字面量，而要测试它所封装的行为（即 checkNumber 的调用效果）；
- 解耦是前提：将 forEach 循环逻辑外提为 checkList(List<Integer>)，才能注入测试数据、控制输入、观察输出；
- 避免依赖 System.out 断言：生产代码中应使用 SLF4J 等日志框架，并在测试中通过 LogCaptor 或 mock logger 验证日志内容；
- 异常处理责任明确：checkNumber 内部 catch 是为了防止中断遍历，因此单元测试需验证该防护生效（即调用 checkList([1,3,2]) 不抛异常，且所有元素均被处理）。
总结：对含 Lambda 的方法做单元测试，本质是提升可测试性设计——通过提取、参数化、减少副作用，让“执行完整性”这一业务需求变得可观测、可验证。
