Detox执行包含网络请求的测试用例时无法正常运行完成

UI测试中点击按钮触发API后步骤迟迟不结束，核心原因是测试框架的应用空闲检测机制判定APP始终处于忙碌状态，和你触发的目标业务API是否返回没有直接关系，从日志可以定位到三个具体阻塞点：

• LaunchDarkly SDK的SSE长连接未豁免：日志中clientstream.launchdarkly.com开头的请求是LaunchDarkly的流式配置拉取长连接，这类连接本身是常驻不主动断开的，默认测试框架会将所有未结束的网络请求判定为忙碌状态，不会自动判定操作完成。
• custommedia接口请求生命周期未正常收尾：主观判断该API已经调用完成，但实际存在回调未执行、任务未标记结束的问题——日志中显示主线程调度队列存在1个待处理工作项，大概率是该接口的回调逻辑没有正确切回主线程、或者某个分支漏写完成回调，导致网络任务状态一直挂起。
• JS计时器阻塞空闲判定：主线程JS上下文里入队了一个触发间隔0.001s的一次性计时器，因为前面的任务阻塞一直没到执行时机，测试框架会将待触发的计时器也识别为未完成的异步任务，持续等待。

1. 处理第三方SDK长连接的测试适配 #

测试环境下不要用LaunchDarkly默认的流式连接模式，避免常驻请求阻塞空闲检测：

// 测试环境初始化LD SDK时修改配置
var ldConfig = LDConfig(mobileKey: "your-mobile-key")
ldConfig.connectionMode = .polling // 改用定期轮询拉取配置，轮询间隔可设为300s以上
// 纯功能测试场景可直接开启离线模式，完全不发起LD相关网络请求
// ldConfig.startOnline = false

如果使用XCTest框架，可直接在启动参数中给第三方埋点、配置类请求添加空闲豁免，不将这类非业务请求纳入空闲判定范围。

2. 排查业务接口的回调逻辑 #

针对/api/v2/custommedia接口逐一检查：

• 成功、失败、超时三个分支是否都正确调用了请求完成回调，是否存在某个分支提前return没执行收尾逻辑
• 回调逻辑是否正确切回主线程执行，有没有在子线程更新UI导致主线程待处理任务卡死
• 抓包确认响应是否完整，有没有出现响应头Content-Length和实际返回body长度不匹配，导致URLSession持续等待剩余数据、任务不结束的问题

3. 优化测试逻辑避免无限等待 #

不要依赖测试框架的自动空闲判定来判断操作完成，改用显式等待目标业务元素出现的逻辑，从根源上避免后台非业务任务阻塞测试流程：

// 点击按钮后不等待全局空闲，直接等待业务结果出现，设置明确超时
let actionButton = app.buttons["targetButton"]
actionButton.tap()
let successTip = app.staticTexts["操作成功"]
XCTAssertTrue(successTip.waitForExistence(timeout: 10), "操作超时未完成")

如果使用Appium等跨端测试框架，可将waitForIdleTimeout参数调整为1s以内，缩短全局空闲等待时间。

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