📚单元测试 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服务器 |
回到顶部
📝判断标准
问自己几个问题：
这个测试需要真实DolphinScheduler服务运行吗？
- 是 → 集成测试
- 否 → 单元测试
测试失败是因为我的代码逻辑问题，还是外部服务问题？
- 代码问题 → 应该用单元测试
- 外部问题 → 集成测试合理
这个测试运行速度重要吗？
- 要快速反馈 → 单元测试
- 可以接受较慢 → 集成测试
回到顶部
✅结论
测试作为集成测试是合理的，特别是：
- 你在开发DolphinScheduler客户端
- 需要验证与真实API的交互
- 早期开发阶段需要端到端验证
但建议补充单元测试来覆盖各种逻辑分支，这样：
- 单元测试：快速验证逻辑（开发时频繁运行）
- 集成测试：验证真实集成（提交前或CI中运行）
现在可以这样做：
// 保持现有的集成测试 |
@SpringBootTest |
class WorkerGroupIntegrationTest { |
// 验证真实连接 |
} |
// 新增单元测试 |
class WorkerGroupRequestUnitTest { |
// 测试所有可能的响应处理逻辑 |
@Test void testParseResponse() { ... } |
@Test void testBuildUrl() { ... } |
@Test void testHandleError() { ... } |
} |
这样既有快速反馈的单元测试，又有保障集成的集成测试。
