为何XCTWaiter.wait()超时不稳定？测试中第二个断言频繁失败

你遇到的问题核心在于**XCTWaiter.wait()的超时机制并非高精度定时器**，再加上测试环境的调度开销，导致实际等待时间经常超出你设定的阈值，进而触发断言失败。咱们一步步拆解：

为什么原代码会出现不稳定的情况？ #

你的execute函数依赖一个永远不会被满足的XCTestExpectation，通过等待超时来执行测试代码。但这种方式存在两个关键问题：

1. XCTWaiter的等待精度有限：XCTWaiter.wait()是基于RunLoop事件循环实现的，它会持续处理当前线程的RunLoop事件直到超时。在测试环境中，主线程可能被XCTest的内部操作（比如日志收集、状态同步）占用，导致RunLoop无法及时处理超时事件，实际等待时间就会比你设定的after值更长。
2. 线程同步与内存可见性隐患：你的testBlock是在测试线程执行的，而i的修改是在主线程的asyncAfter闭包里。虽然Swift的Int在64位平台上读写是原子操作，但跨线程的内存可见性无法保证——不过你这里的主要问题还是等待时间不准，导致asyncAfter提前“赶上”了测试代码的执行。

比如你的第二个execute(after: 0.15)，理论上执行时总耗时是0.2 + 0.15 = 0.35秒，还没到asyncAfter的0.4秒阈值，但如果XCTWaiter.wait()实际等待了0.25秒（而非设定的0.2秒），总耗时就会变成0.25 + 0.15 = 0.4秒，刚好赶上asyncAfter的执行，导致i=2，断言失败。

改进方案：用DispatchQueue实现精准延迟 #

替换掉基于XCTWaiter超时的实现，改用DispatchQueue.asyncAfter来实现延迟，同时结合XCTestExpectation确保测试等待延迟操作完成。这样既保证了延迟精度，又符合XCTest的异步测试规范：

func execute(after: TimeInterval, testBlock: @escaping () -> Void) {
    let delayExpectation = expectation(description: "Wait for delay")
    
    // 用主队列执行延迟，和你的asyncAfter在同一个线程，避免线程同步问题
    DispatchQueue.main.asyncAfter(deadline: .now() + after) {
        testBlock()
        delayExpectation.fulfill()
    }
    
    // 给超时加一点缓冲，避免极端情况的调度延迟
    wait(for: [delayExpectation], timeout: after + 0.5)
}

优化后的测试用例 #

用新的execute函数后，你的测试用例可以保持逻辑不变，但稳定性会大幅提升：

func testExecute() {
    var i = 1
    
    DispatchQueue.main.asyncAfter(deadline: .now() + 0.40) {
        i = 2
    }
    
    execute(after: 0.20) {
        XCTAssert(i == 1)
    }
    
    execute(after: 0.15) {
        XCTAssert(i == 1) // 现在不会再随机失败了
    }
    
    execute(after: 0.06) {
        XCTAssert(i == 2)
    }
}

额外说明 #

• 为什么用主队列？因为你的asyncAfter是在主队列执行的，让testBlock也在主队列执行，可以避免跨线程的内存可见性问题，确保读取的i值是最新的。
• 缓冲超时的作用：虽然asyncAfter的精度很高，但测试环境偶尔还是会有调度抖动，加0.5秒的缓冲超时可以避免因为极端情况导致测试失败，同时不会影响正常的测试逻辑。

内容的提问来源于stack exchange，提问作者meaning-matters