如何简洁实现Sinon存根调用时resolve Promise 优化异步集成测试

这类消息队列集成测试的核心卡点是publishMessage方法仅会等待消息投递到MQ Broker完成，不会感知消费端的业务逻辑执行进度，直接执行断言必然存在时序问题。固定sleep的方案在测试用例量级上来后会大幅拖慢整体执行速度，手写自定义Promise监听的方案样板代码冗余、可读性差，可通过以下两种低冗余、高效率的方案实现：

• 方案1：抽离可复用的Stub调用等待工具 #

把重复的Promise监听逻辑抽成全局通用的测试工具函数，所有同类用例直接复用即可，还可以内置超时兜底逻辑，避免消费异常时测试进程永久挂起：

// 测试目录下的通用工具方法
const waitForStubCall = (stub, timeout = 5000) => {
  return new Promise((resolve, reject) => {
    // 已经调用过直接返回
    if (stub.called) return resolve()
    // 超时兜底
    const timeoutTimer = setTimeout(() => {
      reject(new Error('Wait for stub call exceeded time limit'))
    }, timeout)
    // 劫持stub实现，调用时触发resolve
    const originalImpl = stub.getBehavior?.() || null
    stub.callsFake((...args) => {
      clearTimeout(timeoutTimer)
      setImmediate(resolve)
      return originalImpl?.call(stub, ...args) ?? Promise.resolve()
    })
  })
}

测试用例可以简化到几行核心逻辑，没有冗余样板：

it("should trigger the use case", async () => {
  const stub = sinon.stub(app, 'useCaseToTrigger').resolves()
  await publishMessage({ id: "SOME_ID" })
  await waitForStubCall(stub)
  stub.should.have.been.calledWith(match({id: "SOME_ID" }))
})

• 方案2：使用通用条件轮询等待工具 #

实现一个轻量的通用轮询工具，不需要修改stub的默认实现，直接轮询检查断言条件是否满足，通用性更强，除了等待stub调用外，还可以覆盖等待数据库写入完成、缓存更新、接口返回等各类异步测试场景：

// 通用异步等待工具
const waitFor = async (checkCondition, { timeout = 5000, pollInterval = 10 } = {}) => {
  const startTime = Date.now()
  while (Date.now() - startTime < timeout) {
    try {
      if (checkCondition()) return
    } catch (err) {
      // 条件不满足时忽略断言错误，继续轮询
    }
    await new Promise(resolve => setTimeout(resolve, pollInterval))
  }
  throw new Error('Wait for condition exceeded time limit')
}

测试用例写法更直白，不需要额外处理stub逻辑：

it("should trigger the use case", async () => {
  const stub = sinon.stub(app, 'useCaseToTrigger').resolves()
  await publishMessage({ id: "SOME_ID" })
  await waitFor(() => stub.calledWith(match({id: "SOME_ID" })))
  // 条件满足后直接执行后续逻辑，无额外等待开销
})

额外优化提示：如果消费端代码完全可控，也可以在测试环境给消费逻辑增加完成事件钩子，消息消费执行完成后触发对应事件，测试代码直接监听事件即可，时序判断会更精准，但该方案需要少量修改业务代码，侵入性比前两个纯测试侧的方案更高。

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