imbajin commented on PR #704:
URL: 
https://github.com/apache/incubator-hugegraph-toolchain/pull/704#issuecomment-3767995883

   ## 📋 测试覆盖建议
   
   此 PR 涉及核心的并发控制和错误处理逻辑,**强烈建议**补充以下测试用例以确保逻辑正确性:
   
   ---
   
   ### 1. 批量插入失败处理测试
   
   #### 测试场景 A: 批量失败快速停止模式(默认行为)
   ```java
   @Test
   public void testBatchInsertFailureWithFallbackDisabled() {
       // 前置条件: batchFailureFallback = false (默认值)
       
       // 模拟批量插入失败(如网络错误、服务端拒绝等)
       // 
       // 验证点:
       // 1. context.stopLoading() 被调用
       // 2. context.occurredError() 被调用
       // 3. summary.metrics(struct).flighting 计数器正确归零
       // 4. 后续任务不再被提交到线程池
       // 5. 用户看到错误提示消息
   }
   ```
   
   #### 测试场景 B: 批量失败降级模式(兼容旧行为)
   ```java
   @Test
   public void testBatchInsertFailureWithFallbackEnabled() {
       // 前置条件: batchFailureFallback = true
       
       // 模拟批量插入失败
       // 
       // 验证点:
       // 1. submitInSingle() 被调用
       // 2. 批次中的记录逐条插入
       // 3. flighting 计数器在单条插入完成后正确减少
       // 4. 加载任务继续执行,不会停止
   }
   ```
   
   #### 测试场景 C: 多次批量失败的计数器累积
   ```java
   @Test
   public void testMultipleBatchFailuresCounterConsistency() {
       // 模拟连续多个批次失败
       // 
       // 验证点:
       // 1. 每次失败后 flighting 计数器都正确处理
       // 2. 最终计数器归零,无累积错误
       // 3. 信号量(semaphore)正确释放
   }
   ```
   
   ---
   
   ### 2. 并发竞态条件测试
   
   #### 测试场景 D: 停止信号的并发可见性
   ```java
   @Test
   public void testConcurrentSubmitWhenStopping() {
       // 设置: 10 个线程并发提交 batch
       // 
       // 执行:
       // 1. 线程 1-9 正常执行
       // 2. 线程 10 的批量插入失败,触发 stopLoading()
       // 
       // 验证点:
       // 1. 其他正在 acquire semaphore 的线程能快速感知停止信号
       // 2. 停止后没有新任务被提交到 CompletableFuture
       // 3. 所有线程最终正常退出,无死锁
       // 4. semaphore 计数正确,无泄漏
   }
   ```
   
   #### 测试场景 E: 停止检查的时序正确性
   ```java
   @Test
   public void testStopCheckTimingInSubmitBatch() {
       // 模拟时序:
       // 1. 线程 A 通过 stopped() 检查
       // 2. 线程 A 进入 semaphore.acquire() 阻塞
       // 3. 线程 B 调用 stopLoading()
       // 4. 线程 A 被唤醒,acquire 成功
       // 
       // 验证点:
       // 线程 A 在 acquire 后应该再次检查 stopped(),并及时退出
   }
   ```
   
   ---
   
   ### 3. 连接池自动调整逻辑测试
   
   #### 测试场景 F: 使用默认 batch-insert-threads
   ```java
   @Test
   public void testConnectionPoolAutoAdjustWithDefaultBatchThreads() {
       // 前置条件:
       // - batchInsertThreads 未设置(使用默认 CPUS)
       // - maxConnections 未设置(使用默认 CPUS*4)
       // 
       // 验证点:
       // maxConnections 应等于 CPUS * 4
       // maxConnectionsPerRoute 应等于 CPUS * 2
   }
   ```
   
   #### 测试场景 G: 自定义 batch-insert-threads 触发调整
   ```java
   @Test
   public void testConnectionPoolAutoAdjustWithCustomBatchThreads() {
       // 前置条件:
       // - batchInsertThreads = 20
       // - maxConnections 和 maxConnectionsPerRoute 未设置(使用默认值)
       // 
       // 假设 CPUS = 8,默认值分别为 32 和 16
       // 
       // 验证点:
       // maxConnections 应被调整为 20 * 4 = 80
       // maxConnectionsPerRoute 应被调整为 20 * 2 = 40
       // 日志输出调整信息
   }
   ```
   
   #### 测试场景 H: 用户自定义连接池不被覆盖
   ```java
   @Test
   public void testConnectionPoolNoAdjustWithCustomMaxConn() {
       // 前置条件:
       // - batchInsertThreads = 20
       // - maxConnections = 100 (用户自定义)
       // - maxConnectionsPerRoute = 50 (用户自定义)
       // 
       // 验证点:
       // maxConnections 保持 100,不被调整
       // maxConnectionsPerRoute 保持 50,不被调整
       // 无调整日志输出
   }
   ```
   
   ---
   
   ### 4. 参数验证和默认值测试
   
   #### 测试场景 I: parseThreads 最小值验证
   ```java
   @Test
   public void testParseThreadsMinValue() {
       // 测试 1: --parser-threads 1
       // 验证是否被 PositiveValidator 接受
       
       // 测试 2: --parser-threads 0
       // 验证是否被拒绝
       
       // 测试 3: --parser-threads -1
       // 验证是否被拒绝
   }
   ```
   
   #### 测试场景 J: parseThreads 默认值在不同 CPU 环境
   ```java
   @Test
   public void testParseThreadsDefaultValue() {
       // 模拟不同 CPU 核心数:
       // - CPUS = 1: 期望 parseThreads = 2
       // - CPUS = 2: 期望 parseThreads = 2
       // - CPUS = 4: 期望 parseThreads = 2
       // - CPUS = 8: 期望 parseThreads = 4
       // - CPUS = 16: 期望 parseThreads = 8
   }
   ```
   
   #### 测试场景 K: --parallel-count 弃用参数兼容性
   ```java
   @Test
   public void testDeprecatedParallelCountParameter() {
       // 测试使用旧参数名:
       // args = ["--parallel-count", "4"]
       // 
       // 验证点:
       // 1. 参数正确解析,parseThreads = 4
       // 2. 输出弃用警告日志(如果实现了的话)
   }
   ```
   
   ---
   
   ### 5. 集成测试建议
   
   #### 测试场景 L: 端到端失败恢复测试
   ```java
   @Test
   public void testEndToEndBatchFailureScenario() {
       // 模拟真实场景:
       // 1. 启动 Loader 加载 10000 条数据
       // 2. 在第 5000 条时模拟服务端批量接口故障
       // 
       // 验证 batchFailureFallback=false:
       // - 加载立即停止
       // - 已加载约 5000 条
       // - 错误信息清晰
       // 
       // 验证 batchFailureFallback=true:
       // - 自动降级到单条模式
       // - 最终加载完成 10000 条
       // - 性能有所下降但数据完整
   }
   ```
   
   ---
   
   ### 测试优先级建议
   
   **P0 (必须):**
   - 测试场景 A: 批量失败快速停止模式
   - 测试场景 D: 停止信号的并发可见性
   
   **P1 (强烈推荐):**
   - 测试场景 B: 批量失败降级模式
   - 测试场景 C: 多次批量失败的计数器累积
   - 测试场景 G: 自定义 batch-insert-threads 触发调整
   
   **P2 (建议):**
   - 其他所有场景
   
   ---
   
   ### 现有测试文件位置
   根据项目结构,建议在以下位置添加测试:
   - 单元测试: 
`hugegraph-loader/src/test/java/org/apache/hugegraph/loader/test/unit/`
   - 功能测试: 
`hugegraph-loader/src/test/java/org/apache/hugegraph/loader/test/functional/`
   
   可以创建新文件:
   - `LoadOptionsTest.java` - 参数解析和连接池调整测试
   - `TaskManagerFailureTest.java` - 批量失败处理和并发测试
   - `LoaderFailureRecoveryTest.java` - 端到端集成测试


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]


---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to