1

私のアプリ コード コンポーネントは、Q.js の promise を返す非同期メソッドを提供する依存コンポーネントを呼び出すことがよくあります。可能な限り、そのような外部コンポーネントの同期テストを書きたいと思います...主に同期テストの方が読みやすいためですが、依存コンポーネントがいつ「準備ができている」かを知ることはほとんど不可能である可能性があるためです(以下で説明します)

テスト中に同期的に動作するように構成できるように、依存コンポーネントを設計しました。しかし、彼らの API は依然として Q.js の promise を返します。このようなプロミスは「すぐに」完全に解決されますが (例: return Q(some_data);)、Q はプロミスが次のティックまで実際に解決されないことを保証します。これにより、解決までの時間が実質的にゼロの場合でも、非同期動作が (適切に) 保証されます。

わかった。

しかし、それはつまり、アプリ コンポーネントの同期テストを作成できず、すぐに使える promise がいつ解決されるかを制御できないということです。依存コンポーネントが呼び出し元にプロミスを公開していない場合、コードをまったくテストできません...依存コンポーネントAPIのメソッドが頻繁に発生するように、起動して忘れる必要がある場合は、これを行うべきではありません.

私のテストが「ティック」が発生したことを Q に伝えることができれば、Q はキューに入れられた promise を解決しようとします。このアイデアは、Angular の $q にインスパイアされており、$scope.$applyこの目的のためにこの機能が組み込まれています ( を呼び出します)。

今日、Q で「ティック」をトリガーする方法がわかりません。確かに私はモンキーパンチしたくありませんsetTimeout

私が知らない方法はありますか?これは良い機能でしょうか?

4

1 に答える 1

0

興味深いアイデアです。現在、Q はイベント キューを強制的にフラッシュする方法を提供していません。ほとんどの場合、この機能を提供しないセキュリティ上および安全上の十分な理由があり、非同期システム用の非同期テストを作成することをお勧めします。アクティブな貢献者のパネルからアイデアに関するフィードバックを聞きたいので、Q の次世代イベント キューの実装であるASAP (リンク)に問題を提出しました。

于 2013-10-25T01:10:20.437 に答える