Spring Boot集成测试的测试条件与异常场景处理相关问题咨询

问题1：我可以针对Service或者Repository类编写集成测试吗？ #

完全可以，这是Spring Boot项目中非常常规的集成测试场景：

• 针对Repository层的集成测试：通常配合@DataJpaTest注解启动切片上下文，会自动配置内存数据库、JPA相关组件，直接调用Repository方法校验和数据库的交互逻辑是否符合预期，自定义SQL、查询规则、约束校验都可以在这层完成测试。
• 针对Service层的集成测试：一般使用@SpringBootTest（可指定web环境为NONE，无需启动web服务），加载Service、Repository相关的完整Bean上下文，不需要Mock底层依赖，直接走真实调用链路，验证Service逻辑和底层Repository、数据库的协作是否正常。

问题2：测试上述Service的create方法时，我原本认为只需要在测试类中构造合法的CountryRequest请求参数，传入create方法后校验返回值即可，这个认知是否正确？还是我需要同时测试if子句中countryRepository.existsByCodeIgnoreCase(countryCode)的校验逻辑？ #

这个认知是不完整的，你需要同时覆盖if子句的校验逻辑。
集成测试的核心是验证组件交互的完整链路是否符合预期，这段重复编码校验本身就是create方法核心业务逻辑的一部分，属于必须覆盖的场景，你需要编写两个测试用例：

• 正常场景：数据库中不存在对应code的国家，调用create方法后校验返回的DTO属性正确，数据库确实插入了对应记录
• 异常场景：提前往数据库插入对应code的国家，再调用create方法，校验是否正确抛出EntityAlreadyExistsException，同时数据库没有新增重复记录
  如果只测试正常返回，等于漏了核心的重复校验逻辑，后续如果有人误删了这个if判断，你的集成测试也无法发现问题。

问题3：测试查询类方法时，我认为应当先调用create方法创建测试记录，且该操作的合适放置位置是@BeforeEach setup()方法，这个认知是否正确？ #

这个认知在大多数场景下是合理的，可根据实际情况调整：

• 如果你的多个查询测试用例依赖的测试数据完全一致，放在@BeforeEach中是最佳实践，能避免每个用例重复编写构造数据的代码，保证每个用例执行前的数据状态一致。
• 注意事项：最好在@AfterEach中添加数据清理逻辑，或者直接使用Spring测试默认的事务自动回滚能力（Spring测试默认会给测试方法加事务，执行完自动回滚，无需手动清理），避免不同测试用例之间的数据干扰。
• 如果不同的查询用例依赖的测试数据差异很大，那单独在各自的用例中构造数据更合适，避免@BeforeEach中构造太多不需要的冗余数据，降低测试可读性。

内容的提问来源于stack exchange，提问作者user17186249