如何测试依赖其他服务的Java Spring Boot Maven服务？

作为Spring Boot新手，刚接触Mockito注解时踩坑太正常了，而且网上相关内容好多都是Angular的，确实容易找错方向。你现在用重载方法的临时方案虽然能跑通测试，但并没有真正测试依赖注入后的服务真实行为，业务逻辑复杂后这种方式会越来越臃肿。下面是资深开发者常用的Mockito标准解决方案：

第一步：清理临时代码，回归真实依赖逻辑 #

先把OtherService里的重载方法去掉，恢复它原本依赖ConfigService的逻辑——这才是我们要测试的生产环境真实场景：

@Service
public class OtherService {
    private final ConfigService configService;

    // 推荐用构造器注入（比@Autowired字段注入更适合测试，也符合Spring最佳实践）
    public OtherService(ConfigService configService) {
        this.configService = configService;
    }

    public String printLine() {
        StringBuilder output = new StringBuilder();
        for (int i = 0; i < configService.getInitialLength(); i++) {
            output.append("-");
        }
        return output.toString();
    }
}

注：构造器注入能保证依赖不可变，避免空指针，同时让测试时的依赖注入更清晰可控。

第二步：用Mockito编写标准单元测试 #

我们需要模拟ConfigService的行为，完全控制它的返回值，以此验证OtherService的逻辑是否正确。使用JUnit 5 + Mockito的写法如下：

import org.junit.jupiter.api.Test;
import org.junit.jupiter.api.extension.ExtendWith;
import org.mockito.InjectMocks;
import org.mockito.Mock;
import org.mockito.junit.jupiter.MockitoExtension;
import static org.junit.jupiter.api.Assertions.assertEquals;
import static org.mockito.Mockito.when;

@ExtendWith(MockitoExtension.class) // 初始化Mockito测试上下文
class OtherServiceTest {

    @Mock // 创建ConfigService的模拟对象
    private ConfigService configService;

    @InjectMocks // 自动将模拟的ConfigService注入到OtherService实例中
    private OtherService otherService;

    @Test
    void printLine_shouldReturnCorrectDashesBasedOnConfig() {
        // 模拟ConfigService的getInitialLength方法返回测试值
        when(configService.getInitialLength()).thenReturn(5);

        // 调用待测试方法
        String result = otherService.printLine();

        // 验证结果是否符合预期
        assertEquals("-----", result);
    }

    @Test
    void printLine_withShorterConfigValue() {
        // 换个测试值，覆盖不同场景
        when(configService.getInitialLength()).thenReturn(3);

        String result = otherService.printLine();

        assertEquals("---", result);
    }
}

这种方案的优势 #

• 贴近生产逻辑：测试的是依赖注入后的真实服务行为，和线上运行逻辑完全一致
• 场景覆盖灵活：可以轻松模拟ConfigService的各种返回值，覆盖边界场景
• 代码可维护性高：不用写冗余的重载方法，后续修改业务逻辑时测试代码同步调整更简单

补充：如果暂时不想改构造器注入 #

如果你坚持用@Autowired字段注入的写法，测试类的逻辑完全一致，只是OtherService保持你原来的字段注入即可——但还是强烈推荐构造器注入，这是Spring官方推崇的最佳实践。

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