特定の条件下で例外がスローされることを確認し、例外がスローされない場合はテストに失敗するように TestNG テストを作成したいと思います。余分なブール変数を作成せずにこれを行う簡単な方法はありますか?
このテーマに関する関連ブログ投稿: http://konigsberg.blogspot.com/2007/11/testng-and-expectedexceptions-ive.html
特定の条件下で例外がスローされることを確認し、例外がスローされない場合はテストに失敗するように TestNG テストを作成したいと思います。余分なブール変数を作成せずにこれを行う簡単な方法はありますか?
このテーマに関する関連ブログ投稿: http://konigsberg.blogspot.com/2007/11/testng-and-expectedexceptions-ive.html
@Test(expectedExceptions)
最も一般的な場合に役立ちます。
ドキュメントによると、noexpectedException
がスローされた場合、テストは失敗します。
テスト メソッドがスローすると予想される例外のリスト。例外がスローされない場合、またはこのリストの例外がスローされる場合、このテストは失敗としてマークされます。
@Test(expectedExceptions)
では不十分ないくつかのシナリオを次に示します。
そのような場合は、従来の (TestNG 以前の) パターンに戻す必要があります。
try {
// your statement expected to throw
fail();
}
catch(<the expected exception>) {
// pass
}
@Test
アノテーションを使用して、予想される例外を確認します。
@Test(
expectedExceptions = AnyClassThatExtendsException.class,
expectedExceptionsMessageRegExp = "Exception message regexp"
)
または、例外メッセージを確認したくない場合は、以下だけで十分です
@Test(expectedExceptions = AnyClassThatExtendsException.class)
そうすれば、醜い try catch ブロックを使用する必要はなく、テスト内で例外スローアー メソッドを呼び出すだけです。
採用されたテスト手法の性質に関する記事には同意できません。このソリューションでは、ゲートを使用して、中間段階でテストが成功するか失敗するかを検証します。
私の意見では、特にそのようなテストではGuard Assertionsを採用する方が良いと思います (テスト自体がアンチパターンである、長々と複雑にならないと仮定します)。ガード アサーションを使用すると、次のいずれかの方法で SUT を設計する必要があります。
ただし、上記の可能性を検討する前に、次のスニペットをもう一度見てください。
plane.bookAllSeats();
plane.bookPlane(createValidItinerary(), null);
bookPlane() をテストし、そのメソッドの実行を検証することが意図されている場合は、フィクスチャに bookAllSeats() を含めることをお勧めします。私の理解では、bookAllSeats() を呼び出すことは、SUT を設定して bookPlane() の呼び出しが失敗することを保証することと同じです。したがって、同じことを行うためのフィクスチャがあれば、より読みやすいテストになります。意図が異なる場合は、失敗の元の原因を特定するのに役立つように、すべての遷移後に状態をテストすることをお勧めします (機能テストで通常行うように)。
catch-exceptionは、予想される例外をテストするために必要なすべてを提供します。
リンク先のブログ投稿に記載されている try/fail/catch パターンを使用しないのはなぜですか?