0

この問題は、「async」とマークされたテスト ケースが失敗した場合に発生します。その場合、アプリは単にクラッシュし、TargetInvocationFail の未処理の例外が発生します。私が理解している限り、テストアプリはこれらの例外を処理することになっています。例外の場合、それぞれのケースを失敗としてマークする必要があるためです。これは、通常のテスト ケース (async / await を含まない) で発生することとまったく同じです。

これについても問題レポートを作成しました。 http://phone.codeplex.com/workitem/10751を参照してください。同じ問題がある場合は、問題に賛成票を投じてください。また、回避策を知っている場合は、ここでお知らせください。

EDIT : Stephen Cleary がコメントで述べたように、この問題は、私のテスト ケース プロシージャが async Task ではなく async void であったことが原因でした。この質問を次のように再定式化します。テスト ケースの戻り値の型を変更すると、例外処理の動作が変わるのはなぜですか?

4

2 に答える 2

3

良い一般的なガイドラインは「避けるasync void」です。この理由の1つは、例外処理の違いです。async Taskメソッドは、返されたに例外を配置します。これは、 ed時にTask観察できます。メソッドは、メソッドの開始時に現在のものに直接例外を発生させます。Taskawaitasync voidSynchronizationContextasync void

覚えておくべきもう一つのことは、それasyncは主にコンパイラー変換であるということです。あなた(または他の誰か)がasync Task実行時にメソッドを反映している場合は、戻り型がTask;のメソッドが表示されます。同様に、async voidメソッドの戻りタイプはvoid。です。

したがって、テストランナーは、メソッドが返されるのを見るとvoid(それがメソッドであることを知らずにasync void)、それを実行し、例外を(直接)発生させることなく返されるのを見て、「合格」としてマークします。一方、そのasync voidメソッドによってスローされた例外は直接発生しSynchronizationContext(MSTestを含むほとんどのテストランナーはスレッドプールを提供しますSynchronizationContext)、この例外により、テスト実行で非特定のエラーが報告される可能性があります。テストの実行は十分な速さで完了します。

最新のテストランナー(VS2012以降のMSTestを含む)async Taskは、の戻りタイプを検出することでメソッドを理解し、テストメソッドが「終了」したと見なして合格(または戻りに例外が含まれている場合は失敗)とマークする前に、が完了Taskするのを待ちます。 。TaskTask

のブログのMSTestにこの動作の例があります(競合状態の両方の出力を示すスクリーンショットを含む)が、これらのブログエントリはほぼ1年前のものでありasync、VS2010での単体テストについて説明しています。MSTestはVS2012で更新されたため、async Taskメソッドに対して適切な動作をします。

于 2013-01-18T15:14:58.953 に答える
0

SL/WP ツールキットのクラッシュで発生した主な問題は、テストが失敗した後に TestComplete をアサートまたは呼び出すか、TestComplete を 2 回呼び出すことによって引き起こされました。例: タイムアウト属性でテストをマークし、タイムアウトよりも時間がかかる Web リクエストを待っているとします。webrequest が失敗したのではなく単に遅かった場合でも、単体テスト フレームワークが完了したと見なした後、戻ってきて TestComplete() を呼び出します。テストがタイムアウトしたかどうかをテストする方法がわからないので、それを防ぐためにテストを書くことができるので、これらのシナリオのいくつかでは使用しないことをお勧めします。

もう 1 つのシナリオは、たとえば「完了」イベントと「失敗」イベントの 2 つのイベントを待機し、どちらか一方が発生した場合に別のことを行うが、どちらも TestComplete を呼び出すというものです。コードが誤って両方のイベントを発生させたとしましょう = > test complete を呼び出したところ、コードが失敗しました。3 番目のシナリオは、共有オブジェクトがある場合です。たとえば、各テストで再作成しない WebClient インスタンスを考えてみましょう。最初のテストは DownloadString をリッスンし、それを実行します。次のテストも、実行時に DownloadString のリッスンを開始しますが、古いテストがフックを解除していないため、DownloadStringCompleted イベント ハンドラーが再度実行され、単体テストがクラッシュします。

Stephen が言及しているように、SL および WP 単体テスト フレームワークでは Task を返すことはできません。私はそれを Silverlight 単体テスト ランナーにハックすることに成功しました。 -support-returning-Task.aspx Windows Phone の単体テストでも同様に実行したいと考えていますが、そのソース コードは入手できませんが、こちらからリリースに投票してください: http://phone .codeplex.com/workitem/10642

また、Task のサポートを単体テスト フレームワークに追加するために投票してください: http://phone.codeplex.com/workitem/10727 (WinPhone) およびここ: http://silverlight.codeplex.com/workitem/11457 (Silverlight)

于 2013-01-18T15:47:14.953 に答える