Spring Boot测试中@Mock的必要性：直接注入依赖为何可行？

核心区别 #

• 实例本质不一样
  直接注入的是实打实的Spring Bean，会跟着Spring上下文一起初始化，它的所有逻辑、依赖都是真实运行的；而@Mock造出来的是个“假对象”，是Mockito生成的代理类，本身没有任何真实业务逻辑，全靠你在测试里给它预设行为。
• 测试的范围和速度差很多
  直接依赖注入属于集成测试范畴，得启动Spring上下文，加载相关Bean，跑起来速度较慢，适合验证多个组件配合的逻辑是否正确；用@Mock属于单元测试范畴，不用启动Spring，只专注当前类的功能验证，测试执行速度极快。
• 对依赖的可控性天差地别
  用真实依赖的话，它会按照自身逻辑运行，比如调用数据库就真的会进行读写操作；而Mock对象的行为完全由你掌控，想让它返回特定数据就返回特定数据，想让它抛出异常就抛出异常，各种极端场景都能轻松模拟，不受真实依赖的限制。

适用场景 #

优先用@Mock的情况 #

• 你只想测试单个类的核心逻辑，不想被依赖组件的复杂逻辑或外部资源（如数据库、第三方接口）干扰时。比如测试Service层时，不想真的连接数据库，就可以把依赖的Repository Mock掉。
• 需要测试异常分支、边界情况时，比如模拟依赖超时、返回错误的场景，真实依赖很难复现这些情况，Mock可以轻松搞定。
• 依赖组件还未开发完成，或者依赖的初始化成本极高（比如需要连接外部支付、短信服务），用Mock可以提前开展当前类的测试工作。
• 追求测试执行速度，不想每次跑测试都等待Spring上下文启动时。

适合直接注入依赖的情况 #

• 需要验证多个组件之间的协作逻辑是否正确时，比如Service调用Repository完成数据读写，这时候需要真实的Repository实例来验证数据流转是否符合预期。
• 测试配置类、Bean初始化逻辑时，确保依赖的Bean能被Spring正确创建和注入。
• 需要测试完整业务流程时，比如从接口请求到数据库存储的全链路验证，这时候需要真实的依赖来模拟生产环境的真实行为。

代码示例 #

使用@Mock的单元测试 #

@ExtendWith(MockitoExtension.class)
public class UserServiceTest {
    // Mock依赖的UserRepository
    @Mock
    private UserRepository userRepository;
    
    // 自动将Mock对象注入被测试类
    @InjectMocks
    private UserService userService;
    
    @Test
    public void testGetUserById() {
        // 预设Mock对象的返回值
        when(userRepository.findById(1L)).thenReturn(Optional.of(new User(1L, "test")));
        
        User result = userService.getUserById(1L);
        
        assertEquals("test", result.getName());
        // 验证Mock方法是否被调用
        verify(userRepository, times(1)).findById(1L);
    }
}

直接注入依赖的集成测试 #

@SpringBootTest
public class UserServiceIntegrationTest {
    // 注入真实的UserService和UserRepository
    @Autowired
    private UserService userService;
    
    @Autowired
    private UserRepository userRepository;
    
    @Test
    public void testGetUserById() {
        // 先插入测试数据到数据库
        userRepository.save(new User(1L, "test"));
        
        User result = userService.getUserById(1L);
        
        assertEquals("test", result.getName());
    }
}

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