单元测试与集成测试：测试框架选择、测试用例设计、覆盖率与质量门禁

核心原理：测试金字塔与分层策略

在端到端自动化交付链路中，测试并非一个阶段，而是贯穿代码提交到制品产出的质量防线。单元测试与集成测试处于金字塔的底部与中部，承担着“快速反馈、精准定位”的职责。单元测试验证单个函数、类或模块在隔离环境下的行为，而集成测试则验证多个模块之间通过接口、数据库、消息队列或外部服务协作时的契约与数据流是否正确。二者共同构成质量门禁的第一道和第二道关卡，任何一层失效都会导致缺陷向上游漂移，最终在端到端测试或生产环境中以更高成本暴露。

测试框架的选择应遵循语言生态与项目约束。以Java/Spring生态为例，JUnit 5（含Jupiter）是事实标准，配合AssertJ提供流式断言，Mockito用于隔离外部依赖；对于异步或响应式代码，Awaitility可编写时序敏感断言。Python项目则常选pytest，其fixture机制与参数化能力天然适合数据驱动测试。JavaScript/TypeScript项目可选用Jest或Vitest，内置断言与mock能力。选择框架时需同时考虑CI环境兼容性、报告格式（JUnit XML、Cobertura、JaCoCo）、与覆盖率工具的集成成本。

测试金字塔与门禁位置

方法流程：从用例设计到门禁落地

测试用例设计不是简单覆盖所有方法，而是基于行为与边界的工程实践。推荐采用输入-行为-输出三元组描述用例，并优先覆盖：正常路径、边界值（如数值上限、空字符串、超长文本）、异常路径（非法参数、依赖超时、返回null）、以及状态转换（如订单状态从“待支付”到“已取消”）。对于单元测试，应保证每个用例独立运行，不依赖执行顺序，不访问真实网络或文件系统；对于集成测试，则需明确被测模块的上下游依赖，使用Testcontainers或H2等内存数据库模拟真实环境。

覆盖率是质量门禁的量化指标，但并非唯一标准。行覆盖率（Line Coverage）与分支覆盖率（Branch Coverage）应同时关注，分支覆盖率更能反映逻辑判断的完整性。建议将单元测试的行覆盖率阈值设为80%，分支覆盖率设为70%；集成测试则关注关键接口的调用链覆盖，而非追求数字最大化。在CI流水线中，使用JaCoCo（Java）、pytest-cov（Python）或Istanbul（JS）生成报告，并通过插件（如SonarQube）解析结果，当低于阈值时直接使流水线失败。

// 示例：使用JUnit 5 + Mockito编写单元测试
public class OrderServiceTest {
    @Mock
    private PaymentClient paymentClient;
    @InjectMocks
    private OrderService orderService;

    @Test
    void shouldCreateOrderWhenPaymentSucceeds() {
        when(paymentClient.charge(any(PaymentRequest.class)))
            .thenReturn(new PaymentResponse("SUCCESS", "txn_123"));
        Order order = orderService.createOrder(new OrderRequest("SKU-100", 2));
        assertThat(order.getStatus()).isEqualTo(OrderStatus.CONFIRMED);
        verify(paymentClient, times(1)).charge(any(PaymentRequest.class));
    }

    @Test
    void shouldThrowExceptionWhenPaymentFails() {
        when(paymentClient.charge(any(PaymentRequest.class)))
            .thenThrow(new PaymentException("insufficient funds"));
        assertThatThrownBy(() -> orderService.createOrder(new OrderRequest("SKU-100", 2)))
            .isInstanceOf(OrderCreationException.class)
            .hasMessageContaining("payment failed");
    }
}

案例场景：订单服务与库存系统的集成测试

以一个典型的微服务订单模块为例，订单服务在创建订单时需要调用库存服务扣减库存，并发送消息到消息队列。单元测试阶段，我们使用Mockito将库存客户端和消息生产者全部mock掉，只验证订单状态流转与异常处理逻辑。而集成测试阶段，则启动一个真实的Spring Boot测试上下文，使用Testcontainers启动MySQL与RabbitMQ容器，验证以下链路：

订单服务通过HTTP调用库存服务，库存充足时返回成功并扣减库存；
库存不足时返回失败，订单服务回滚本地事务并抛出明确异常；
消息队列中能收到订单创建事件，且消息体包含订单号与商品编码；
数据库中的订单记录与库存扣减记录保持最终一致。

该集成测试用例使用@SpringBootTest与@Testcontainers注解，通过@DynamicPropertySource动态注入容器端口。测试运行时间约15秒，远快于端到端测试的分钟级耗时，且能精准定位是接口契约问题、数据库事务问题还是消息序列化问题。

误区与复盘：常见陷阱及规避策略

误区一：过度mock导致测试失真。单元测试中mock掉所有依赖，虽然隔离了外部因素，但可能掩盖了接口参数不匹配、序列化错误等真实问题。建议对第三方SDK或远程服务使用mock，但对本地模块间的交互尽量使用真实实现或轻量级替身（如内存数据库）。

误区二：覆盖率数字崇拜。盲目追求100%行覆盖率，却忽略了分支覆盖与异常路径。例如一个if (a && b)条件，行覆盖可能只测了a=true, b=true一种组合，而分支覆盖要求测试四种组合。应使用变异测试（如Pitest）辅助评估用例有效性。

误区三：集成测试环境不稳定。依赖外部共享数据库或测试环境导致测试结果随机失败。应使用容器化依赖（Testcontainers）或独立测试实例，确保可重复执行。

复盘一个真实案例：某团队在CI中仅配置了单元测试门禁，覆盖率85%通过，但合并到主干后集成测试频繁失败。排查发现，单元测试中mock的库存服务返回参数与真实服务不一致（真实服务返回stockCode字段，而mock返回code），导致反序列化时字段映射失败。修复措施是在集成测试中增加契约测试（Consumer-Driven Contracts），使用Spring Cloud Contract验证服务间请求/响应结构，并将该契约测试纳入合并请求的门禁条件。此后，此类问题在开发阶段即被拦截，集成测试失败率下降90%。

最终，质量门禁的落地应遵循“快速反馈、分层卡点”原则：提交代码时触发单元测试与静态分析，合并请求时触发集成测试与覆盖率检查，发布前执行端到端冒烟测试。每一层门禁的失败都应提供清晰的报告与责任人通知，确保问题在最短时间内被修复，从而保障整个交付流水线的顺畅与可靠。