Java单元测试这件事很多团队其实并没有真正做起来。大多数项目有测试和有有效的测试是两码事——CI里跑绿是一回事测试到底能不能在改动代码时给你兜住问题又是另一回事。这篇文章我不想讲大道理直接拆一个常见的业务模块把单元测试和集成测试从头到尾怎么设计、怎么写、怎么集成进工程流程一步步说透。适合刚接触测试的初级开发也适合已经在写测试但总觉得不得要领、想系统梳理一遍的同学。1. 测试基础设施搭建依赖选型与工程配置先解决最容易被忽视的工程问题测试依赖到底怎么选版本怎么配目录和模型怎么约定。1.1 框架组合与版本选择现在Java测试的主流组合是 JUnit 5 Mockito AssertJ集成测试再叠加 Testcontainers。这个组合不是随便拼出来的每一层都有各自的职责JUnit 5Jupiter负责测试的生命周期、用例组织、参数化执行、动态测试。相比JUnit 4Jupiter最大的优势是扩展模型Extension设计得非常干净Spring、Mockito这些框架都有独立的扩展点后续集成时不会出现各种版本冲突。Mockito负责打桩和交互校验解决单元测试里的外部依赖隔离问题。相比EasyMock和PowerMockMockito社区活跃、语法简洁目前也是Spring Boot默认集成的Mock框架。如果你需要对静态方法、构造方法做Mock需要使用mockito-inline版本。AssertJ负责断言。你当然可以用JUnit自带的Assert类但AssertJ的流式断言assertThat(...).extracting(...).containsExactly(...)写出来的断言可读性高一个档次失败时输出的对比信息也友好很多。Testcontainers负责集成测试里的真实环境。它能在测试启动时拉起真实的数据库、消息队列、Redis容器而不是用内存版替代品去假装环境一致。选型时直接踩过一个大坑只引入了JUnit 4的老坐标结果Spring Boot的SpringBootTest完全不生效。Spring Boot 2.2以上对JUnit 5是原生支持的但如果工程里同时存在JUnit 4和JUnit 5的依赖IDE和Maven会用旧版本执行测试导致注解全部失效。配置依赖时需要把JUnit 4的坐标排除干净统一使用Jupiter聚合坐标。1.2 工程目录与命名约定推荐在模块根目录下严格区分三套目录src/test/java存放所有测试代码。src/test/resources存放测试专用配置文件、Fixture数据、SQL脚本。src/integrationTest/java需配置Maven profile来激活存放真正的集成测试不让它在普通构建阶段执行。实际测试代码和业务代码放在同一个包路径下例如业务代码是com.example.order.service测试代码就放在com.example.order.service这样不仅能享受包内可见性比如测试同包的package-private方法也方便IDE自动跳转和维护。命名约定我用的是被测类名Test订单服务就是OrderServiceTest集成测试统一用被测类名ITOrderRepositoryITCargo/运行器会通过后缀区分单元测试和集成测试CI里可以分别控制执行时机避免单元测试每次构建都要启动Spring容器。1.3 贴近实战的基准配置如果工程用的是Maven需要特别关注maven-surefire-plugin的配置。默认情况下它会扫描*Test.java以及Test*等类名。为了让*IT.java不被单元测试阶段误执行需要配置Surefire排除掉*IT同时用Failsafe插件单独管理集成测试。构建工具这块我不重复贴大段配置但有一个关键点值得写出来在Gradle中要区分test和integrationTest这两个SourceSet否则Testcontainers启动的容器会在每次跑build时都被拉起本地开发会非常痛苦。2. 单元测试实战从能跑到跑得有意义单元测试的目标不是覆盖率数字而是快速定位回归。这里我基于一个模拟订单结算模块来拆解。2.1 被测业务建模与测试思路假设业务里有这样一个方法根据订单的原始金额、用户折扣、优惠券减免、运费计算最终应付金额。方法签名是BigDecimal computeFinalAmount(BigDecimal rawAmount, BigDecimal discountRate, BigDecimal couponAmount, BigDecimal shippingFee)。这个方法单独拎出来测看起来很简单但实际写测试时会暴露出一堆设计问题金额是BigDecimal那么在测试里对精度做断言时不能直接用assertEquals(50, result)因为数值绝对相等在浮点和精度处理上是不可靠的。折扣、减免、运费之间还有业务规则比如运费不参与满减优惠券金额不能大于商品金额。这些规则是否由方法自己负责校验还是由外部调用方负责直接影响测试用例的边界怎么设计。我在测试前会先画一张输入—输出表格把正常路径、边界路径、异常路径全部列出。比如正常折扣50%优惠券20元运费10元极端的优惠券金额大于订单金额负数的输入参数折扣大于1打超过一折的折扣。然后为被测方法建立测试类用场景化命名。推荐使用方法名_场景_期望结果三段式比如computeFinalAmount_negativeRawAmount_throwException或者更贴近中文团队习惯的计算金额_参数为负_抛异常。个人实践下来英文加下划线在IDE里搜索定位更顺手场景描述里带上业务语义。2.2 第一个用例的编写思路用JUnit 5写第一个用例核心是遵循AAA三段式Arrange准备输入、Act执行被测方法、Assert验证结果。Test void computeFinalAmount_discountAndCoupon_applyBothRules() { BigDecimal rawAmount new BigDecimal(100.00); BigDecimal discountRate new BigDecimal(0.80); BigDecimal couponAmount new BigDecimal(10.00); BigDecimal shippingFee new BigDecimal(6.00); BigDecimal result orderService.computeFinalAmount(rawAmount, discountRate, couponAmount, shippingFee); BigDecimal expectedDiscountPrice rawAmount.multiply(discountRate); // 80 BigDecimal afterCoupon expectedDiscountPrice.subtract(couponAmount); // 70 BigDecimal expected afterCoupon.add(shippingFee); // 76 assertThat(result).isEqualByComparingTo(expected); }这里有两个很实用的断言细节。一是isEqualByComparingTo而不是isEqualTo。BigDecimal的equals会比较精度new BigDecimal(76.0)和new BigDecimal(76.00)不相等compareTo只比较数值所以在金额断言上必须用isEqualByComparingTo。二是我不会在测试里手算预期值而是把这个方法拆成独立步骤来计算预期因为这些计算本身也是业务规则的一部分如果预期值直接写死后续调整规则时测试代码也要同步改得很痛苦。很多人在这一步会问Mock在哪里用这个计算方法是纯业务逻辑没有外部依赖所以不需要Mock。单元测试的第一原则是不要让假的依赖污染真实的逻辑测试。如果被测方法依赖了别的服务比如查用户折扣、查库存才需要用Mockito去替换那些与当前测试目标无关的组件。2.3 Mockito的正确用法隔离依赖但不要过度Mock继续下单场景。订单服务在结算时需要从用户服务查询折扣率从促销服务查询可用优惠券列表。在单元测试里我们只关心OrderService自己的结算逻辑所以把UserService和PromotionService都Mock掉。ExtendWith(MockitoExtension.class) class OrderServiceTest { Mock private UserService userService; Mock private PromotionService promotionService; InjectMocks private OrderService orderService; Test void checkout_externalServiceCalled_computeCorrectTotal() { BigDecimal rawAmount new BigDecimal(200.00); when(userService.getDiscountRate(userId)).thenReturn(new BigDecimal(0.90)); when(promotionService.getApplicableCoupons(userId, rawAmount)) .thenReturn(List.of(new Coupon(10_OFF, new BigDecimal(10.00)))); CheckoutResult result orderService.checkout(userId, rawAmount, shippingFee); assertThat(result.getFinalAmount()) .isEqualByComparingTo(new BigDecimal(170.00)); verify(userService).getDiscountRate(userId); verify(promotionService).getApplicableCoupons(userId, rawAmount); } }这个用例里有一个很多人看不出来的细节断言和verify分别验证了什么。断言验证的是结算金额的数值正确——这是被测方法的核心价值verify验证的是外部服务是否按照预期被调用——这是为了确保我们Mock出来的交互关系是真实的。如果被测方法某个分支下不应该调用促销服务但代码里却调了单靠断言可能根本发现不了因为Mock默认返回null金额计算可能仍然碰巧对。这时verify(promotionService, never()).getApplicableCoupons(any(), any())就能精准捕获错误。Mockito的when是打桩一个返回值。这里有个教训打桩时若参数是动态值尽量用any()或eq()明确指定匹配器一旦你有一个参数用了匹配器所有参数都必须用匹配器。否则Mockito会抛InvalidUseOfMatchersException排查起来会绕圈子。2.4 参数化测试把表驱动测试的价值发挥到最大纯计算逻辑是最适合参数化测试的场景。与其写十几个几乎重复的Test方法不如用ParameterizedTest配合CsvSource一次性把边界值全部覆盖。ParameterizedTest CsvSource({ 100.00, 0.80, 10.00, 6.00, 76.00, 0.00, 0.80, 0.00, 6.00, 6.00, 100.00, 0.80, 200.00, 0.00, 0.00, 100.00, 1.10, 0.00, 0.00, 110.00 }) void computeFinalAmount_variousInputs_expectedResult(String raw, String rate, String coupon, String shipping, String expected) { BigDecimal result orderService.computeFinalAmount( new BigDecimal(raw), new BigDecimal(rate), new BigDecimal(coupon), new BigDecimal(shipping)); assertThat(result).isEqualByComparingTo(new BigDecimal(expected)); }参数化测试最值钱的地方在于可读性测试报告里可以清楚看到每一行输入对应的执行结果出问题时一眼就能定位到是哪组参数。而字符串转BigDecimal这种写法虽然是偷懒但对于测试数据来说完全够用更严谨的做法是使用MethodSource返回Arguments对象适合需要输入对象或集合的场景。2.5 单元测试的边界与反模式单元测试还有一些常见的反模式我踩过的坑都在这里测试私有方法这是一个反模式。应该通过公开方法的行为来间接验证私有逻辑如果私有方法复杂到需要单独测说明它应该被提取为一个独立类或包级可见方法。使用PowerMockPowerMock能Mock静态方法和私有方法但它会改变类加载方式拖慢测试并且与新版JaCoCo配合时会出现兼容问题。从设计上消除静态调用比引入PowerMock强得多。一个用例测多个逻辑一个Test里又验算金额又验证用户被调用又验证异常信息一旦失败你无法判断到底是哪段逻辑出了问题。每个测试方法只验证一个行为这是保证可排查性的底线。3. 集成测试落地真实环境下的数据、事务与外部依赖单元测试能覆盖业务逻辑但很多问题只有在真实组件协作时才会暴露SQL写得对不对、事务边界是否生效、MyBatis映射是否完整、Redis序列化是否匹配。这些是集成测试的战场。3.1 Spring切片测试与全上下文测试的取舍Spring Boot提供了强大的测试切片体系。DataJpaTest只加载JPA相关的配置不会启动整个MVC或服务层WebMvcTest只加载Web层JsonTest只加载JSON序列化。切片测试启动快适合聚焦某一层但它默认不会加载你自定义的配置类、过滤器、拦截器。所以需要明确场景仓库层Repository的SQL映射问题用DataJpaTest。Controller层的参数绑定、序列化、异常处理用WebMvcTest MockMvc。涉及完整链路Controller - Service - Repository - 数据库的流程验证才用SpringBootTest。我通常把切片测试放在fast test阶段全上下文测试单独归入slow integrationTest。3.2 用容器化数据库替代H2为什么不再用内存库模拟很多人早期会用H2做集成测试因为它启动快、无需Docker。H2确实快但它和MySQL在SQL方言、锁机制、事务隔离级别上存在实质差异。最常见的翻车现场H2上跑通的SQL发到MySQL就报语法错误H2上能通过的分页查询MySQL里查出了重复数据。这不是H2的错而是集成测试的意义本就在于验证真实环境行为。Testcontainers的用法非常直接在测试启动时拉起一个MySQL容器测试结束自动销毁。Testcontainers class OrderRepositoryIT { Container static MySQLContainer? mysql new MySQLContainer(mysql:8.4) .withDatabaseName(order_test) .withUsername(test) .withPassword(test); DynamicPropertySource static void registerProperties(DynamicPropertyRegistry registry) { registry.add(spring.datasource.url, mysql::getJdbcUrl); registry.add(spring.datasource.username, mysql::getUsername); registry.add(spring.datasource.password, mysql::getPassword); } Test Transactional void saveAndFindById_persistOrder_returnMatch() { OrderEntity entity new OrderEntity(); entity.setOrderNo(20250601001); entity.setTotalAmount(new BigDecimal(99.00)); orderRepository.saveAndFlush(entity); OrderEntity found orderRepository.findByOrderNo(20250601001); assertThat(found).isNotNull(); assertThat(found.getId()).isNotNull(); } }这段代码里几个配置细节值得解释Container static静态容器会在所有测试之前启动所有测试共享同一个实例。如果不用static每个测试方法都会重建容器白白浪费十几秒。DynamicPropertySource在Spring上下文创建之前把动态JDBC URL注入配置源。这是Spring Boot 2.5之后推荐的方式。Transactional测试方法加事务结束时自动回滚。这样测试不会污染数据库也无需手动清理数据。3.3 测试数据准备从SQL脚本到对象工厂集成测试里最繁琐的是数据准备。推荐三种策略分层使用对于仓库层的简单场景在BeforeEach里用JPA的saveAndFlush直接保存对象。对于需要关联多张表的复杂场景使用Sql注解在测试方法前执行构造好的SQL脚本。对于跨测试复用的标准数据用户、商品、店铺等建议用对象工厂类来创建避免到处散落SQL片段。这里有一个经验集成测试里的数据必须是显式的。看不懂默认数据长什么样的测试是最难维护的测试。与其在BeforeAll里悄悄插入一批数据让每个方法都隐式依赖不如让每个测试自己组装它需要的最小数据集。3.4 外部HTTP服务的集成模拟如果被测试服务需要调用第三方HTTP接口比如查询物流状态、调用支付网关集成测试不建议使用Mockito去Mock整个HTTP调用因为这样无法验证HTTP客户端的序列化、超时、重试逻辑。正确姿势是用WireMock启动一个本地HTTP服务器返回预设的JSON响应。BeforeAll static void configureWireMock() { wireMockServer new WireMockServer(options().port(18080)); wireMockServer.start(); stubFor(post(urlEqualTo(/api/v1/pay/query)) .willReturn(aResponse() .withHeader(Content-Type, application/json) .withBody({\status\:\SUCCESS\,\tradeNo\:\W20250601001\}))); }这样被测服务真实地向指定地址发起了HTTP请求整个客户端逻辑都被验证到了速度比Docker容器快得多。4. 测试覆盖率与CI流水线集成让质量门禁真实生效很多团队接入JaCoCo之后只看一个数字绿色就放行。其实覆盖率工具用得好不好差别很大。4.1 覆盖率的多维度评估行覆盖率只是最基础的指标我日常工作更关注两个维度分支覆盖率分支覆盖代表所有if/else、switch分支都被执行过。行覆盖率90%但分支覆盖率只有40%说明创新分支异常处理、边界条件大概率没测到。增量覆盖率改动代码的覆盖率。存量代码覆盖率低是历史包袱不应该让新人每次提交都背这个锅但也绝对不能因为存量低就放弃卡点。如果你的工程已经运行了一段时间直接用总体覆盖率≥80%作为门禁往往会陷入补了很多测试但都是在测老代码的尴尬。更务实的做法是首次接入时以增量覆盖为门槛存量代码允许逐步提升但新代码覆盖率必须达到阈值。JaCoCo的配置关键在于exec数据文件和报告路径。CI里要区分report阶段和check阶段check里可以设定branch覆盖率“最小”值用excludes排除掉生成的DTO、配置类以及一些琐碎的内部类。否则这些模板代码会把覆盖率稀释得非常好看但实际业务逻辑一点都没被测试到。4.2 测试金字塔在CI里的工程化理想中的测试执行频率应该这样安排每次IDE保存时开发者本机执行fast test单元测试 切片测试秒级反馈。每次推送到远程分支CI执行fast test 合并请求分支上的增量覆盖检查。合并到主干后夜间流水线执行integrationTest全上下文 Testcontainers并把报告归档。有一点容易被忽略单元测试和集成测试要能并行跑。单元测试本身很快但Testcontainers要拉镜像、启动容器耗时不可控。如果挤在同一条流水线里CI排队时间会变成团队抵触写测试的最大理由。4.3 从构建工具到质量门禁的完整闭环假设你用的Gradle测试任务可以拆成test、integrationTest、jacocoTestReport、jacocoTestCheck四级。这里我建议把integrationTest定义为dependsOn test这样执行./gradlew check时先跑单元测试再跑集成测试顺序清晰结果也能被统一聚合到覆盖率报告里。CI里的质量门禁不是越高越好它需要能解释的门槛。一个务实的参考线新代码增量行覆盖≥80%。新代码增量分支覆盖≥70%。旧代码总体行覆盖不低于接入时的基线。单元测试执行时间控制在5分钟以内超过这个时间就要考虑拆模块或者并行执行。4.4 覆盖率报告的阅读技巧JaCoCo生成的HTML报告建议重点看两个区域一个是按包展开的Missed Instructions列另一个是每个类的Complexity列。如果某个类的复杂度指数很高但覆盖率低说明这个类里有很多条件分支没被测试覆盖应该优先补用例而不是去补那些简单getter/setter的下半身覆盖率。5. 常见问题与排查技巧实录5.1 测试之间的数据污染症状单独跑某个测试通过全量跑却失败而且失败用例不固定。排查思路先检查是否有测试在断言前依赖了其他测试的数据。Transactional能回滚JPA操作但不能回滚手动生成的数据库自增ID也不能清理Redis里的缓存。所以在集成测试中如果测试方法里显式修改了公共数据比如写Redis、调用真实的外部接口要么把它们Mock掉要么在AfterEach里手动清理。5.2 SpringBootTest上下文启动极慢全上下文测试会加载整个应用如果你的配置类里有Bean执行了耗时的初始化逻辑比如启动时预热缓存、加载第三方凭据每个测试类启动都会遭殃。解决方案按优先级尽量用切片测试不要动辄SpringBootTest。多个测试类共享同一个Spring上下文缓存Spring在测试中会自动缓存已加载的上下文但条件是配置完全相同。要想充分利用缓存就得避免每个测试类都写不同的MockBean或动态属性——每次上下文配置变化都会导致缓存失效。对于必须全上下文加载的场景把耗时初始化逻辑移到PostConstruct里用Profile(test)在测试环境跳过。5.3 测试偶现失败Flaky TestFlaky测试最典型的来源是时间与并发。比如断言里用了Thread.sleep(1000)来等待异步完成CI负载高时1000毫秒不够测试就挂。解决办法是不要等待固定时间而是使用Awaitility这类工具做条件轮询await().atMost(Duration.ofSeconds(10)) .untilAsserted(() - assertThat(orderEventCaptor.getValue()).isNotNull());另外测试代码里直接new Random()、LocalDateTime.now()都会让断言变得不稳定。推荐通过参数传入或Clock注入的方式使时间可控。5.4 Mockito与Spring上下文Bean冲突在SpringBootTest里使用MockBean要格外小心。它会把Mock对象注入Spring容器替换掉真实的Bean。如果两个不同的测试类对同一个Bean做了不同的MockBean配置Spring上下文缓存将无法复用每次都要重新启动。更隐蔽的问题在于MockBean默认是“没有打桩就返回默认值”如果一个Bean在正常启动时从配置中心拉取数据被MockBean替换后相关配置会瞬间变为null接着测出一堆奇怪的NPE。解决方案在集成测试里尽量少用MockBean优先让真实Bean参与测试。如果只是验证某个外部依赖的交互可以把这个依赖的客户端单独抽象接口集成测试里用条件装配TestConfigurationPrimary替换为桩实现。5.5 参数化测试中CSV转义问题CsvSource里如果字段包含逗号需要用单引号包住整段内容如果字段本身包含单引号则需要两个单引号转义。写测试时遇到CSV解析异常大部分是转义没处理好。更稳妥的方式是改用MethodSource来提供参数尤其是参数包含复杂对象时CSV只适合简单的基础类型。5.6 MySQL容器启动失败Testcontainers启动MySQL容器失败常见原因有三类Docker环境本身没启动Windows的DockerDesktop、Linux的Docker daemon未运行。端口被占用默认映射的3306冲突。容器拉取镜像超时尤其在内网环境。排查方法是从日志中确认Testcontainers在哪个阶段失败。如果拉镜像超时可以在公司内部配置Docker镜像仓库加速如果端口冲突为MySQLContainer调用withMapping自定义映射端口即可。6. 把测试变成开发流程的一部分最后分享几条我个人在多个项目里实践出来的体会不一定每条都适合所有团队但值得做参考。第一个体会是测试是设计质量的反馈器而不是代码数量的放大器。如果一个方法很难写测试往往不是测试难写而是这个方法的职责太多、依赖太散、可预测性太差。这种情况应该先重构被测代码而不是硬凑Mock。写测试的时间花得值不值全看这一条怎么把握。第二个体会是测试需要分层考虑执行成本与反馈速度。单元测试追求秒级反馈集成测试追求真实可靠两者目标不同不要混在一个池子里。把慢测试和快测试分开管理才能让写完代码先跑测试成为开发者的肌肉记忆而不是因为等待时间过长逐渐放弃执行。第三个体会是看测试报告的经验。刚接触覆盖率工具时我喜欢把目标设定成体检一个数字后来发现覆盖到每一个函数不等于每一个逻辑都被验证过。真正靠谱的做法是在改动代码的时刻看到选中代码的直接覆盖率。用IDE的Run with Coverage功能跑一次单测看看自己写的代码哪些没被覆盖这对补用例的指导意义远比最终汇总的百分比更直接。Java测试这条路的门槛不高但要做到改代码不怕、发版本不慌靠的是日常把测试融入编码动作而不是最后集中冲刺。希望这篇基于实际项目经验的拆解能帮你少踩一些已经踩过的坑。