Spring Boot service层应编写单元测试还是集成测试？

你提供的BookService代码如下：

@Service
@Transactional
@RequiredArgsConstructor
public class BookService {

    private final BookRepository bookRepository;

    public Book findOne(Long id) {
        return bookRepository.findById(id).orElse(null);
    }

    public Book getOne(Long id) {
        return bookRepository.findById(id)
                .orElseThrow(() -> new BadRequestAlertException("entity-not-found", ("Entity with id: " + id + " not found!")));
    }

    public List<Book> getAll() {
        return bookRepository.findAll();
    }

    public Book save(Book book) {
        return bookRepository.save(book);
    }
}

针对以上代码及你提到的测试覆盖情况，判断如下：

你提到的分层测试通用实践符合绝大多数项目的落地规范，你当前的场景下不需要额外编写Service层的集成测试。

无需补充测试的依据 #

你已经完成的三类测试已经可以覆盖所有逻辑场景：

• Repository层集成测试：已经验证了所有数据库CRUD操作的正确性
• Service层单元测试：通过Mock BookRepository的方式，已经覆盖了Service所有业务分支，包括getOne方法抛自定义异常、findOne返回null等边界场景
• Controller层集成测试：会加载完整Spring上下文触发全链路调用，已经天然验证了Service层和上下层的串联逻辑，不需要重复测试

需要补充Service层集成测试的例外场景 #

只有当你的Service层存在以下特性，现有测试无法覆盖对应逻辑时，才需要补充：

• Service除了调用Repository外，还依赖其他中间件或外部服务（如缓存、RPC接口、消息队列），单元测试中全部Mock了这些依赖，需要验证真实交互的兼容性
• Service有复杂的@Transactional事务配置（如自定义传播行为、回滚规则），单元测试无法验证事务是否真实生效
• Service关联了AOP切面逻辑（如权限校验、操作日志、监控埋点），单元测试未加载完整Spring上下文，无法验证切面逻辑是否正常触发

你提供的BookService逻辑非常简单，仅做Repository的透传调用，没有额外复杂逻辑和其他依赖，现有测试覆盖度已经完全足够。

你提到的分层测试通用规则是行业普遍落地的最佳实践：

• Controller - 集成测试
• Service - 单元测试
• Repository - 集成测试

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