2

例外のスローのシミュレーションに関するこの質問を読みました。回答は、実際のオブジェクトのふりをするモックオブジェクトを作成することを示唆しています。

それは私が望んでいることではありません。実際のオブジェクトを置き換えると、実際のコードの一部が失われます。最小限の変更で実際のコードを呼び出し、そのコードのランダムなポイントでその内部から例外をスローしたいと思います。

ユニットテストから呼び出されるコードのランダムなポイントで例外がスローされる可能性はありますか？

4

3 に答える 3

3

ユニットテストにランダム性を入れないでください。それはあなたにトラブルをもたらすだけです。単体テストには常にある程度の一貫性が必要です。特に、彼が赤くなったときに何が悪かったのかを彼に話してもらいたい場合は。ユニットテストにランダムな例外スローを実装すると、クラッシュして赤いバーが返されることがあります。たぶん次の実行でエラーは再び消えました。これは実際には単体テストの目的ではなく、一度発生した失敗したテストの問題を見つけるのに大きな問題が発生します。

はるかに優れたアプローチは、コードの重要な部分を体系的にテストすることです。重要な各メソッドをモックオブジェクトに置き換えます。これにより、テストする例外のタイプがスローされ、このように各テストケースがカバーされます。これにより、そのエラーを探しているときに何がうまくいかなかったかについて、より多くの情報が得られます。

お役に立てれば。

于 2013-03-05T13:56:30.340 に答える
1

この回避策について考えることができます。

1- RandomException（）;という関数を作成します。throwランダムな値が3で割り切れる場合はその例外、それ以外の場合は例外をスローしません。この関数がこのコードブロックにカプセル化されていることを確認してください。

#if DEBUG
void RandomException()
{
    // gen random value
    // if random value % 3 == 0 throw the exception now
}
#else
void RandomException()
{
}
#endif

そうすれば、コードをリリースするときに、これらの関数呼び出しはプログラムに影響を与えません。

そのアイデアがお役に立てば幸いです。

于 2013-03-05T12:12:12.653 に答える
1

例外処理をテストしようとしているようです。これは、例外をランダムにスローして、それが発生するかどうかを確認するための良いアプローチではないと思います。特定の条件で処理をテストする必要がある場合は、実際に条件をシミュレートする必要があります。例外を引き起こすはずの違法な状況のようなオブジェクト。

（ユニットテストで）外部から設定できるローカル変数を使用してこの動作を生成することもできます。これにより、コードはこの変数に応じて例外をスローしますが、前述のように、これは良いアプローチではないと思います。

于 2013-03-05T12:22:44.583 に答える