私はユニットテストとnUnit(2.48)を初めて使用します。デッドロックが発生するというテストメソッドを作成したいと思います。これは可能ですか?明らかに、nUnitはデフォルトでメソッドの実行にかかる時間を認識しないため、別のスレッドで作業を行うためのコードを記述し、それを中止して、定義した時間がかかる場合は例外をスローする必要がありますか?これを行うためのより良い方法はありますか?
ありがとうございました
私はユニットテストとnUnit(2.48)を初めて使用します。デッドロックが発生するというテストメソッドを作成したいと思います。これは可能ですか?明らかに、nUnitはデフォルトでメソッドの実行にかかる時間を認識しないため、別のスレッドで作業を行うためのコードを記述し、それを中止して、定義した時間がかかる場合は例外をスローする必要がありますか?これを行うためのより良い方法はありますか?
ありがとうございました
別のスレッドでコードを実行し、タイムリーにコードが返されるかどうかを確認することで、デッドロックをテストすることは確かに可能です。次に、いくつかの(非常に基本的な)サンプルコードを示します。
[TestFixture]
public class DeadlockTests
{
[Test]
public void TestForDeadlock()
{
Thread thread = new Thread(ThreadFunction);
thread.Start();
if (!thread.Join(5000))
{
Assert.Fail("Deadlock detected");
}
}
private void ThreadFunction()
{
// do something that causes a deadlock here
Thread.Sleep(10000);
}
}
これが「最善の方法」であるとは言いたくありませんが、私が時々役立つと思った方法です。
デッドロックの検出は停止問題と同等であるため、現在、一般的なケースでは解決できません。
防御すべき特定の問題がある場合は、少なくともある程度のセキュリティを確保するための特定のハッキングが存在する可能性があります。ただし、これはハックにすぎず、100%になることはないことに注意してください。たとえば、このようなテストは常に開発マシンでは合格しますが、本番マシンでは合格しません。
それは可能ですが、最善の方法ではないかもしれません。単体テストは、同時実行動作のテストにはあまり適していません。残念ながら、適切なテスト方法はあまりありません。
NUnit はスレッドに対して何もしません。複数のスレッドを開始するテストを作成し、それらの相互作用をテストできます。しかし、これらは単体テストというよりも統合テストのように見え始めます。
もう 1 つの問題は、デッドロックの動作は通常、スレッドがスケジュールされている順序に依存することです。そのため、特定のデッドロックの問題をテストするための決定的なテストを作成するのは難しいでしょう。スレッドのスケジュールを制御できないためです。 OS。マルチコア プロセッサでは失敗することもあるが、シングル コア プロセッサでは常に成功するテストになる可能性があります。
「Chess」という Microsoft Project を見てみましょう。同時発生したバグを見つけるように設計されていますhttp://research.microsoft.com/en-us/projects/chess/
デッドロックをテストするには、単体テストで状態グラフと現在の状態グラフのサイクルのチェックを実装する必要があります。状態グラフは、ノードとしてのリソースとエッジとしての依存関係で構成されます。私はそのようなことの実装についてはわかりませんが、それは理論です。
単体テストは、アプリケーションの実行フローの正確さではなく、データの入力と出力(主に後のポイント)の正確さをテストします。
マーク・ヒースの考えは合理的であるように見えますが、学術的には間違っています。