2

基本的に - 私たちは単体テストを書きます。これらの単体テストがスレッドを開始することもあれば、スレッドプールでタスクを開始することもよくあります。バックグラウンド スレッドで何か問題が発生した場合、将来のテストで奇妙な問題が発生する可能性があります。各テストの基本分解でやりたいことは基本的に

  • 実行中のスレッドを確認する
  • 実行すべきではないものが実行されている場合、テストに失敗します

現在、通常のスレッドの場合は、事前に列挙し、後で比較することができます。これは問題ありません。スレッドプールは物事を台無しにします-有効に作成された多くの新しいスレッドが存在する可能性があり、それらは何もせずに待っているだけです-これは問題ありません。テストで何かが実行されたままになっている場合は問題ありません。また、覚えておいてください-私はテストやテスト対象のコードを書いているのではありません-私は、他の誰も物事を台無しにできないようにするための基礎となるライブラリを書いているのです.誰かが標準のものを使用していないかどうかわからないので、スレッドプールなど。

スレッドプールによって所有されているスレッドと、それらがアイドル状態であるかどうかを確認する方法を考えられる人はいますか? 私の次のステップは、リフレクションを見てプライベート変数をクロールすることですが、誰かがより良い方法を持っていることを願っていますか?

ありがとう、ダレン

4

1 に答える 1

0

ファイア アンド フォーゲット スタイルのスレッド/タスク/ワークアイテムを使用していると思います。そうでない場合は、テスト後も実行し続けるという問題はありません。

単体テスト (本番環境) 以外でも、エラーを決して忘れたくないため、ファイア アンド フォーゲットは問題のあるパターンであると考えています。また、ASP.NET では、保留中のすべての HTTP 要求が処理された後、バックグラウンド作業が完了する前にワーカー プロセスがシャットダウンする可能性があるため、バックグラウンド作業が完了する保証はありません。

したがって、コードを監査して、すべての同時実行を新しい にTask基づくモデルに切り替えることをお勧めします。これにより、完了を追跡できます。また、完了を待ってエラーを伝播することもできます。

すべての開始済みタスクをリストに追加できます（おそらくカスタムを使用してTaskScheduler、おそらく手動で）。単体テストがシャットダウンしたらTask.WaitAll、そのリストの内容に対して a を実行します。それはあなたの完成を保証します。

いずれにせよ、スレッドプールでは、キューに入れられたアイテムや完了をリッスンすることはできません。独自のコードでこれを解決する必要があります。

于 2013-08-05T09:37:28.497 に答える