Java单元测试、集成测试，区别

📚 单元测试 vs 集成测试

1. 单元测试（Unit Test）

定义：测试最小代码单元（通常是一个方法或类），隔离所有外部依赖。

特点：

• 测试单个类/方法
• 所有依赖都用Mock代替
• 不启动Spring容器
• 运行极快（毫秒级）
• 数量最多

示例：

// 测试OrderService的calculateTotal方法
class OrderServiceTest {
    @Test
    void calculateTotal_ShouldReturnCorrectSum() {
        // 1. Mock所有依赖
        DiscountService discountMock = mock(DiscountService.class);
        when(discountMock.calculate(any())).thenReturn(10.0);
        
        // 2. 创建被测试对象（不通过Spring）
        OrderService service = new OrderService(discountMock);
        
        // 3. 调用并验证
        Order order = new Order(100.0);
        double total = service.calculateTotal(order);
        
        assertEquals(90.0, total);  // 100 - 10折扣
    }
}

2. 集成测试（Integration Test）

定义：测试多个组件协同工作，验证它们之间的集成是否正确。

特点：

• 测试组件间交互
• 启动部分或全部Spring容器
• 可能连接真实数据库/外部服务
• 运行较慢（秒级）
• 数量较少

典型集成测试：

@SpringBootTest  // ← 启动完整Spring Boot应用
class DolphinSchedulerApiDemoApplicationTests {
    @Autowired  // ← Spring注入真实bean
    WorkerGroupRequest workerGroupRequest;  // ← 测试这个bean与其他组件的集成
    
    @Test
    void contextLoads() {
        // 调用真实方法，可能涉及：
        // 1. WorkerGroupRequest内部逻辑
        // 2. 它依赖的其他Service
        // 3. 可能的HTTP调用（如果用了RestTemplate）
        // 4. 数据库操作（如果用了DAO）
        workerGroupRequest.getWorkerPaths();
    }
}

📊 两种测试对比

方面	单元测试	集成测试
测试范围	单个类/方法	多个组件/模块
外部依赖	全部Mock	部分或全部真实
Spring容器	不启动	启动
运行速度	快（ms级）	慢（s级）
测试目的	验证逻辑正确性	验证集成正确性
数量比例	70-80%	20-30%

🔧 测试分析

当前情况：

@SpringBootTest  // 启动整个应用 → 集成测试
class DolphinSchedulerApiDemoApplicationTests {
    @Autowired  // Spring注入 → 集成测试
    WorkerGroupRequest workerGroupRequest;
    
    @Test
    void contextLoads() {
        // 测试API客户端与DolphinScheduler的集成
        // 可能涉及：网络调用、JSON解析、错误处理等
    }
}

应该改吗？要看测试目的：

情况1：如果你是想测"WorkerGroupRequest与真实DolphinScheduler服务的交互"

// ✅ 保持集成测试（需要真实后端）
@SpringBootTest
class WorkerGroupIntegrationTest {
    @Autowired WorkerGroupRequest request;
    
    @Test
    void shouldConnectToRealDolphinScheduler() {
        // 验证是否能真正连接到部署的DolphinScheduler
        List<String> paths = request.getWorkerPaths();
        assertNotNull(paths);
        // 可能还需要验证路径格式等
    }
}

情况2：如果你是想测"WorkerGroupRequest内部的逻辑"

// ✅ 改为单元测试（更快、更稳定）
class WorkerGroupRequestTest {
    
    @Test
    void parseWorkerPaths_ShouldHandleEmptyResponse() {
        // 1. Mock HTTP客户端
        RestTemplate restTemplateMock = mock(RestTemplate.class);
        when(restTemplateMock.exchange(any(), any(), any(), eq(String.class)))
            .thenReturn(new ResponseEntity<>("[]", HttpStatus.OK));
        
        // 2. 创建测试对象
        WorkerGroupRequest request = new WorkerGroupRequest(restTemplateMock, "http://localhost");
        
        // 3. 测试内部逻辑
        List<String> paths = request.getWorkerPaths();
        
        assertTrue(paths.isEmpty());
    }
    
    @Test
    void parseWorkerPaths_ShouldParseJsonCorrectly() {
        RestTemplate restTemplateMock = mock(RestTemplate.class);
        String jsonResponse = "[\"192.168.1.1:1234\", \"192.168.1.2:1234\"]";
        when(restTemplateMock.exchange(any(), any(), any(), eq(String.class)))
            .thenReturn(new ResponseEntity<>(jsonResponse, HttpStatus.OK));
        
        WorkerGroupRequest request = new WorkerGroupRequest(restTemplateMock, "http://localhost");
        
        List<String> paths = request.getWorkerPaths();
        
        assertEquals(2, paths.size());
        assertEquals("192.168.1.1:1234", paths.get(0));
    }
}

🎯 具体建议

方案A：保持集成测试，但要改进

@SpringBootTest
// 限制测试范围，加速启动
@AutoConfigureMockMvc
@TestPropertySource(locations = "classpath:test.properties")
class WorkerGroupRequestIntegrationTest {
    
    @Autowired
    private WorkerGroupRequest workerGroupRequest;
    
    @MockBean  // Mock某些不想真实调用的依赖
    private SomeExternalService externalService;
    
    @Test
    void getWorkerPaths_ShouldReturnListFromDolphinScheduler() {
        // 配置Mock行为
        when(externalService.someCall()).thenReturn("mocked");
        
        // 执行测试
        List<String> result = workerGroupRequest.getWorkerPaths();
        
        // 更专业的断言
        assertNotNull(result);
        assertFalse(result.isEmpty());
        // 可以验证特定的业务逻辑
    }
}

方案B：拆分为两种测试

// 1. 单元测试：测逻辑（80%的测试）
class WorkerGroupRequestUnitTest {
    // 测试各种场景：正常情况、异常情况、边界情况
    @Test void testNormalCase() { ... }
    @Test void testEmptyResponse() { ... }
    @Test void testMalformedJson() { ... }
    @Test void testNetworkError() { ... }
}

// 2. 集成测试：测真实连接（20%的测试）
@SpringBootTest
class WorkerGroupRequestIntegrationTest {
    // 只测真正需要集成验证的部分
    @Test void testRealConnection() { ... }
}

方案C：添加测试配置

在 src/test/resources/application-test.yml：

# 测试专用配置
dolphinscheduler:
  url: http://localhost:12345
  # 或者使用测试专用的Mock服务器

📝 判断标准

问自己几个问题：

1. 这个测试需要真实DolphinScheduler服务运行吗？

   • 是 → 集成测试
   • 否 → 单元测试

2. 测试失败是因为我的代码逻辑问题，还是外部服务问题？

   • 代码问题 → 应该用单元测试
   • 外部问题 → 集成测试合理

3. 这个测试运行速度重要吗？

   • 要快速反馈 → 单元测试
   • 可以接受较慢 → 集成测试

✅ 结论

测试作为集成测试是合理的，特别是：

• 你在开发DolphinScheduler客户端
• 需要验证与真实API的交互
• 早期开发阶段需要端到端验证

但建议补充单元测试来覆盖各种逻辑分支，这样：

1. 单元测试：快速验证逻辑（开发时频繁运行）
2. 集成测试：验证真实集成（提交前或CI中运行）

现在可以这样做：

// 保持现有的集成测试
@SpringBootTest
class WorkerGroupIntegrationTest {
    // 验证真实连接
}

// 新增单元测试
class WorkerGroupRequestUnitTest {
    // 测试所有可能的响应处理逻辑
    @Test void testParseResponse() { ... }
    @Test void testBuildUrl() { ... }
    @Test void testHandleError() { ... }
}

这样既有快速反馈的单元测试，又有保障集成的集成测试。