如何测试Swift中@Published属性的更新与发布通知能力？

这个问题的核心陷阱在于直接用sleep(3)会阻塞主线程，导致你的Timer根本跑不起来——因为你指定了Timer在main runloop上运行，而sleep会卡住主线程的事件循环，定时器完全没法触发事件。咱们用XCTest的异步期望来解决这个问题，这是测试Combine异步流的标准做法：

func testStart() {
    // Given
    let segmentTimer = SampleSegmentTimer()
    var elapsedTimes = [DateComponents?]()
    // 创建一个期望，标记我们要等待3次更新
    let updateExpectation = self.expectation(description: "Receive 3 elapsed time updates")
    updateExpectation.expectedFulfillmentCount = 3
    
    // 订阅@Published属性，每次收到更新就记录，达到次数就完成期望
    let elapsedTimeSub = segmentTimer.$elapsedTime
        .sink { value in
            elapsedTimes.append(value)
            if elapsedTimes.count == updateExpectation.expectedFulfillmentCount {
                updateExpectation.fulfill()
            }
        }
    
    // When
    segmentTimer.start(tickingEvery: 1)
    
    // 等待期望完成，留0.5秒缓冲避免系统调度延迟导致失败
    wait(for: [updateExpectation], timeout: 3.5)
    
    // Then
    XCTAssertEqual(elapsedTimes.count, 3)
}

关键细节解释： #

• XCTestExpectation：这是XCTest处理异步测试的核心工具，我们用它标记需要等待的事件，设置expectedFulfillmentCount为3，代表要等待3次更新触发。
• sink闭包逻辑：每次收到elapsedTime的更新后，我们把值加入数组，当数组长度达到期望的次数时，调用fulfill()告诉测试“我要等的事件完成了”。
• wait(for:timeout:)：这个方法会暂停测试的同步流程，但不会阻塞主线程——它会让runloop继续运行，这样你的Timer就能正常触发事件。超时时间设为3.5秒比3秒多一点，是为了避免系统调度的微小延迟导致测试误判失败。

额外注意事项： #

• 绝对不要用sleep(_:)来等待异步事件：它会彻底阻塞主线程，让依赖main runloop的Timer、UI更新等完全无法执行，这也是你最初的测试会失败的原因。
• 如果需要验证elapsedTime的具体值（而不只是更新次数），可以修改transform方法返回有意义的DateComponents，比如当前的秒数，然后在测试里断言每个元素的内容：

  private func transform(_ date: Date) -> DateComponents {
      Calendar.current.dateComponents([.second], from: date)
  }
  

  之后在测试的Then部分可以添加对具体值的验证（注意Timer的触发可能有微小误差，断言时可以适当宽松）。
• 订阅的生命周期：在这个测试里，elapsedTimeSub会在测试方法结束后被销毁，自动取消订阅，所以不需要手动处理。如果是更复杂的测试场景，可以把订阅存在测试类的属性里，避免提前销毁。

内容的提问来源于stack exchange，提问作者M.Serag