我的应用代码组件经常调用依赖组件，这些组件具有返回 Q.js 承诺的异步方法。我想尽可能编写此类外部组件的同步测试......主要是因为同步测试更具可读性，但也因为几乎不可能知道依赖组件何时"准备就绪"（如下所述）
我已经设计了依赖组件，以便我可以将它们配置为在测试时同步运行。但他们的 API 仍然返回 Q.js 承诺。即使这样的承诺将"立即"完全解决（例如，return Q(some_data);），Q 保证承诺在下一次报价之前不会真正解决。这（正确）确保异步行为，即使解决时间实际上为零。
我明白了。
但这意味着我无法为应用程序组件编写同步测试，也无法控制何时解决准备就绪的承诺。当依赖组件不向调用方公开承诺时，我根本无法测试代码......当依赖组件 API 的方法应该像通常那样即发即弃时，它不应该这样做。
如果我的测试可以告诉 Q 发生了"tick"，从而导致它尝试解决排队的承诺，那就太好了。这个想法的灵感来自Angular的$q，它有这个功能（你称之为$scope.$apply）就是为了这个目的。
我今天看不到任何方法可以在 Q 中触发"即时报价"。当然，我不想打setTimeout猴子！
有没有我不知道的方法？这会是一个好功能吗？
这是一个有趣的想法。Q 不提供任何强制刷新事件队列的方法。在大多数情况下，不提供此功能可能有很好的安全和安全理由，我当然鼓励为异步系统编写异步测试。 我有兴趣听取我们活跃贡献者小组对这个想法的反馈，所以我向 Q 的下一代事件队列实现 ASAP（链接）提出了一个问题。