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() { ... } |
| } |

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