すでに開発されており、展開する準備ができているメトロ アプリがあります。しかし、これまでに行ったテストにはまだ満足していません。アプリ内の特定の重要なイベントを公開する目的でアプリ コード内にインライン テスト コードを記述し (テスト コードが待機できるいくつかのイベントを生成することによって)、テスト コードによって生成されたイベントを待機することを目指しています。より多くのシナリオを生成できます。
たとえば、バックグラウンド スレッド A、B、C、および D として実行されている 4 つのコンポーネントがあり、A が実行され、イベントのコードをテストして待機するように通知する必要がある場合 (UI スレッドが実行されている間はバックグラウンド スレッドでのみ)。次に、テスト コードはいくつかのユーザー アクションをシミュレートし、アプリがアクション B と C を実行するようにアプリに通知し、バックグラウンド スレッドがまだ中断されている間に、テスト コードが UI でいくつかのテスト ケースを再度実行するときに再び待機します。
このようにして、BackgroundThread A-> ユーザー イベント x-> バックグラウンド スレッド B -> バックグラウンド スレッド C -> ユーザー イベント y -> バックグラウンド スレッド D というシナリオを実現しました。
バックグラウンド スレッドが原因で発生する可能性のある同期の問題がさらに見つかることを願っています。このアプローチの背後にある原動力は、スレッドがいつコンテキストから外れるかを制御できないことです。そのため、このようなシナリオをシミュレートして、競合領域をチェックしたいと考えています。すべての基本的な IPC メカニズムを試しましたが、メトロ アプリのサンドボックス化が原因で、メトロ アプリとデスクトップ アプリの間では機能しないようです。