一部のコードが例外をスローすることをテストするために慣用的に JUnit4 を使用するにはどうすればよいですか?
私は確かにこのようなことをすることができますが：
@Test
public void testFooThrowsIndexOutOfBoundsException() {
boolean thrown = false;
try {
foo.doStuff();
} catch (IndexOutOfBoundsException e) {
thrown = true;
}
assertTrue(thrown);
}
この種の状況では、アノテーションやAssert.xyz など、はるかにぎこちなく、はるかに JUnit の精神に則ったものがあることを思い出します。
JUnit のバージョンと、使用するアサート ライブラリによって異なります。
の元の答えJUnit <= 4.12は次のとおりです。
@Test(expected = IndexOutOfBoundsException.class)
public void testIndexOutOfBoundsException() {
ArrayList emptyList = new ArrayList();
Object o = emptyList.get(0);
}
回答https://stackoverflow.com/a/31826781/2986984には、JUnit <= 4.12 のオプションがさらにあります。
参照 ：
編集: JUnit 5 と JUnit 4.13 がリリースされたので、Assertions.assertThrows() (JUnit 5 の場合) とAssert.assertThrows()(JUnit 4.13+ の場合) を使用するのが最適なオプションです。詳細については、他の回答を参照してください。
JUnit 5 に移行していないが、JUnit 4.7 を使用できる場合は、次のExpectedExceptionルールを使用できます。
public class FooTest {
@Rule
public final ExpectedException exception = ExpectedException.none();
@Test
public void doStuffThrowsIndexOutOfBoundsException() {
Foo foo = new Foo();
exception.expect(IndexOutOfBoundsException.class);
foo.doStuff();
}
}
が前にスローされる@Test(expected=IndexOutOfBoundsException.class)とテストが失敗するため、これははるかに優れています。IndexOutOfBoundsExceptionfoo.doStuff()
詳細については、この記事を参照してください。
予期される例外の使用には注意してください。これは、テスト内の特定のコード行ではなく、メソッドがその例外をスローしたことのみをアサートするためです。
パラメータの検証をテストするためにこれを使用する傾向があります。そのようなメソッドは通常非常に単純ですが、より複雑なテストには以下を使用する方がよい場合があります。
try {
methodThatShouldThrow();
fail( "My method didn't throw when I expected it to" );
} catch (MyException expectedException) {
}
判断を適用します。
junit では、例外をテストする方法が 4 つあります。
junit5.xの場合assertThrows、次のように使用できます
@Test
public void testFooThrowsIndexOutOfBoundsException() {
Throwable exception = assertThrows(IndexOutOfBoundsException.class, () -> foo.doStuff());
assertEquals("expected messages", exception.getMessage());
}
junit4.x の場合、テスト注釈のオプションの「expected」属性を使用します
@Test(expected = IndexOutOfBoundsException.class)
public void testFooThrowsIndexOutOfBoundsException() {
foo.doStuff();
}
junit4.x の場合、ExpectedException ルールを使用します
public class XxxTest {
@Rule
public ExpectedException thrown = ExpectedException.none();
@Test
public void testFooThrowsIndexOutOfBoundsException() {
thrown.expect(IndexOutOfBoundsException.class)
//you can test the exception message like
thrown.expectMessage("expected messages");
foo.doStuff();
}
}
また、junit 3 フレームワークで広く使用されている従来の try/catch 方法を使用することもできます
@Test
public void testFooThrowsIndexOutOfBoundsException() {
try {
foo.doStuff();
fail("expected exception was not occured.");
} catch(IndexOutOfBoundsException e) {
//if execution reaches here,
//it indicates this exception was occured.
//so we need not handle it.
}
}
それで
詳細については、このドキュメントとjunit5 ユーザー ガイドを参照してください。
tl;dr
post-JDK8 : AssertJまたはカスタム ラムダを使用して、例外的な動作をアサートします。
trypre - JDK8 : 古き良きcatchブロックをお勧めします。(ブロックの前にアサーションを追加することを忘れないでくださいfail()catch)
Junit 4 または JUnit 5 に関係なく。
長い話
JUnitツール（またはJUnitルール機能）をブロックまたは使用して、自分 tryで書くことができます。catch@Test(expected = ...)@Rule ExpectedException
しかし、これらの方法はそれほどエレガントではなく、他のツールとの読みやすさがうまく調和していません。さらに、JUnit ツールにはいくつかの落とし穴があります。
try-ブロックは、テストされた動作の周りにブロックを記述し、catch ブロックにアサーションを記述する必要があります。catchこれは問題ないかもしれませんが、多くの場合、このスタイルはテストの読み取りフローを中断します。また、ブロックAssert.failの最後にan を記述する必要があります。tryそうしないと、テストでアサーションの片側が見落とされる可能性があります。PMD、findbugsまたはSonarは、そのような問題を発見します。
より少ないコードを記述できるため、この@Test(expected = ...)機能は興味深いものであり、このテストを記述することでコーディング エラーが発生しにくくなると思われます。しかし、このアプローチはいくつかの分野で欠けています。
また、メソッドに期待が置かれているため、テストされたコードの記述方法によっては、テストコードの間違った部分が例外をスローし、誤検知テストにつながる可能性があり、PMD、findbugsまたはSonarかどうかはわかりませんそのようなコードのヒントを提供します。
@Test(expected = WantedException.class)
public void call2_should_throw_a_WantedException__not_call1() {
// init tested
tested.call1(); // may throw a WantedException
// call to be actually tested
tested.call2(); // the call that is supposed to raise an exception
}
このルールは以前の警告を修正する試みでもありますが、 EasyMockユーザーはこのスタイルをよく知ってExpectedExceptionいる期待スタイルを使用するため、使用するのが少しぎこちなく感じます。一部の人にとっては便利かもしれませんが、Behavior Driven Development (BDD) またはArrange Act Assert (AAA) の原則に従う場合、ルールはそれらの記述スタイルには適合しません。それとは別に、期待する場所によっては、方法と同じ問題が発生する可能性があります。ExpectedException@Test
@Rule ExpectedException thrown = ExpectedException.none()
@Test
public void call2_should_throw_a_WantedException__not_call1() {
// expectations
thrown.expect(WantedException.class);
thrown.expectMessage("boom");
// init tested
tested.call1(); // may throw a WantedException
// call to be actually tested
tested.call2(); // the call that is supposed to raise an exception
}
予期される例外がテスト ステートメントの前に配置されていても、テストが BDD または AAA に従っている場合は、読み取りフローが中断されます。
また、の作者の JUnit に関するこのコメントExpectedExceptionの問題も参照してください。JUnit 4.13-beta-2 では、このメカニズムを非推奨にしています。
プル リクエスト #1519 : ExpectedException の廃止
メソッド Assert.assertThrows は、例外を検証するための優れた方法を提供します。さらに、TestWatcher などの他のルールと一緒に使用すると、ルールの順序が重要になるため、ExpectedException を使用するとエラーが発生しやすくなります。
したがって、これらの上記のオプションにはすべての注意事項があり、コーダーエラーの影響を受けないことは明らかです.
この回答を作成した後、有望に見えるプロジェクトに気づきました。それはcatch-exceptionです。
プロジェクトの説明にあるように、コーダーは流暢なコード行を記述して例外をキャッチし、この例外を後者のアサーションに提供できます。HamcrestやAssertJなどの任意のアサーション ライブラリを使用できます。
ホームページからの簡単な例：
// given: an empty list
List myList = new ArrayList();
// when: we try to get the first element of the list
when(myList).get(1);
// then: we expect an IndexOutOfBoundsException
then(caughtException())
.isInstanceOf(IndexOutOfBoundsException.class)
.hasMessage("Index: 1, Size: 0")
.hasNoCause();
コードが非常に簡単であることがわかるように、特定の行で例外をキャッチしthenます。API は、AssertJ API を使用するエイリアスです (を使用するのと同様assertThat(ex).hasNoCause()...です)。ある時点で、プロジェクトは AssertJ の祖先である FEST-Assert に依存していました。編集:プロジェクトは Java 8 ラムダ サポートを作成しているようです。
現在、このライブラリには 2 つの欠点があります。
この記事の執筆時点では、このライブラリが Mockito 1.x に基づいていることは注目に値します。これは、バックグラウンドでテスト対象オブジェクトのモックを作成するためです。Mockito はまだ更新されていないため、このライブラリは final クラスまたは final メソッドでは機能しません。また、現在のバージョンの Mockito 2 に基づいていたとしても、グローバル モック メーカー ( inline-mock-maker) を宣言する必要がありますが、このモック メーカーには通常のモック メーカーとは異なる欠点があるため、これは望ましくない可能性があります。
さらに別のテスト依存関係が必要です。
ライブラリがラムダをサポートすると、これらの問題は適用されなくなります。ただし、機能は AssertJ ツールセットによって複製されます。
catch-exception ツールを使用したくない場合は、すべてを考慮して、少なくとも JDK7 まではtry-ブロックの古い良い方法をお勧めします。catchまた、JDK 8 ユーザーの場合は、AssertJ を使用することを好むかもしれません。AssertJ は、単に例外をアサートするだけではありません。
JDK8 では、ラムダがテスト シーンに入り、例外的な動作をアサートする興味深い方法であることが証明されています。AssertJ が更新され、優れた流暢な API を提供して例外的な動作をアサートできるようになりました。
AssertJを使用したサンプル テスト:
@Test
public void test_exception_approach_1() {
...
assertThatExceptionOfType(IOException.class)
.isThrownBy(() -> someBadIOOperation())
.withMessage("boom!");
}
@Test
public void test_exception_approach_2() {
...
assertThatThrownBy(() -> someBadIOOperation())
.isInstanceOf(Exception.class)
.hasMessageContaining("boom");
}
@Test
public void test_exception_approach_3() {
...
// when
Throwable thrown = catchThrowable(() -> someBadIOOperation());
// then
assertThat(thrown).isInstanceOf(Exception.class)
.hasMessageContaining("boom");
}
JUnit 5 のほぼ完全な書き直しにより、アサーションが少し改善されました。適切に例外をアサートするすぐに使える方法として興味深いことがわかるかもしれません。しかし実際には、アサーション API はまだ少し貧弱で、外部には何もありませんassertThrows。
@Test
@DisplayName("throws EmptyStackException when peeked")
void throwsExceptionWhenPeeked() {
Throwable t = assertThrows(EmptyStackException.class, () -> stack.peek());
Assertions.assertEquals("...", t.getMessage());
}
お気づきのように、assertEqualsまだ返さvoidれているため、AssertJ のようなチェーン アサーションは許可されません。
Matcherまた、またはとの名前の衝突を覚えている場合はAssert、 との同じ衝突に遭遇する準備をしてAssertionsください。
今日 (2017-03-03) AssertJの使いやすさ、検出可能な API、開発の迅速なペース、および事実上のテスト依存関係としての AssertJ は、テスト フレームワーク (JUnitかどうか)、以前の JDK は代わりにtry-catchブロックを使用する必要があります。
この回答は、同じ可視性を持たない別の質問からコピーされたものです。私は同じ著者です。
JUnit 5 と JUnit 4.13 がリリースされたので、Assertions.assertThrows() (JUnit 5 の場合) とAssert.assertThrows()(JUnit 4.13 の場合) を使用するのが最適なオプションです。JUnit 5 ユーザー ガイドを参照してください。
例外がスローされたことを確認し、 Truthを使用して例外メッセージに対してアサーションを作成する例を次に示します。
public class FooTest {
@Test
public void doStuffThrowsIndexOutOfBoundsException() {
Foo foo = new Foo();
IndexOutOfBoundsException e = assertThrows(
IndexOutOfBoundsException.class, foo::doStuff);
assertThat(e).hasMessageThat().contains("woops!");
}
}
他の回答のアプローチに対する利点は次のとおりです。
throws句に予想される例外をリストする必要はありませんこれはどうですか: 非常に一般的な例外をキャッチし、それが catch ブロックの外にあることを確認してから、例外のクラスが期待どおりであることをアサートします。このアサートは、a) 例外の型が間違っていて (たとえば、代わりに Null ポインターを取得した場合)、b) 例外がスローされなかった場合に失敗します。
public void testFooThrowsIndexOutOfBoundsException() {
Throwable e = null;
try {
foo.doStuff();
} catch (Throwable ex) {
e = ex;
}
assertTrue(e instanceof IndexOutOfBoundsException);
}
更新: JUnit5 では例外テストが改善されています: assertThrows.
@Test
void exceptionTesting() {
IllegalArgumentException exception = assertThrows(IllegalArgumentException.class, () -> {
throw new IllegalArgumentException("a message");
});
assertEquals("a message", exception.getMessage());
}
JUnit 4を使用した元の回答。
例外がスローされたことをテストするには、いくつかの方法があります。また、私の投稿で以下のオプションについても説明しましたJUnitで優れた単体テストを作成する方法
expectedパラメータを設定します@Test(expected = FileNotFoundException.class)。
@Test(expected = FileNotFoundException.class)
public void testReadFile() {
myClass.readFile("test.txt");
}
使用するtry catch
public void testReadFile() {
try {
myClass.readFile("test.txt");
fail("Expected a FileNotFoundException to be thrown");
} catch (FileNotFoundException e) {
assertThat(e.getMessage(), is("The file test.txt does not exist!"));
}
}
ExpectedExceptionルールによるテスト。
@Rule
public ExpectedException thrown = ExpectedException.none();
@Test
public void testReadFile() throws FileNotFoundException {
thrown.expect(FileNotFoundException.class);
thrown.expectMessage(startsWith("The file test.txt"));
myClass.readFile("test.txt");
}
Exception testingおよびbad.robot - Expecting Exceptions JUnit Ruleの JUnit4 wiki で例外テストの詳細を読むことができます。
JUnit と一緒に使用できるAssertJアサーションの使用:
import static org.assertj.core.api.Assertions.*;
@Test
public void testFooThrowsIndexOutOfBoundsException() {
Foo foo = new Foo();
assertThatThrownBy(() -> foo.doStuff())
.isInstanceOf(IndexOutOfBoundsException.class);
}
@Test(expected=IndexOutOfBoundsException.class)テストで予想される行が例外をスローしたことを保証し、メッセージなどの例外に関する詳細を簡単に確認できるため、より優れています。
assertThatThrownBy(() ->
{
throw new Exception("boom!");
})
.isInstanceOf(Exception.class)
.hasMessageContaining("boom");
import static com.googlecode.catchexception.apis.BDDCatchException.*;
@Test
public void testFooThrowsIndexOutOfBoundsException() {
when(() -> foo.doStuff());
then(caughtException()).isInstanceOf(IndexOutOfBoundsException.class);
}
eu.codearte.catch-exception:catch-exception:2.0
同じ問題を解決するために、小さなプロジェクトをセットアップしました: http://code.google.com/p/catch-exception/
この小さなヘルパーを使用して、次のように記述します
verifyException(foo, IndexOutOfBoundsException.class).doStuff();
これは、JUnit 4.7 の ExpectedException ルールよりも冗長ではありません。skaffman によって提供されたソリューションと比較して、例外が予想されるコード行を指定できます。これが役立つことを願っています。
これを行うこともできます：
@Test
public void testFooThrowsIndexOutOfBoundsException() {
try {
foo.doStuff();
assert false;
} catch (IndexOutOfBoundsException e) {
assert true;
}
}
私見、JUnit で例外をチェックする最良の方法は、try/catch/fail/assert パターンです。
// this try block should be as small as possible,
// as you want to make sure you only catch exceptions from your code
try {
sut.doThing();
fail(); // fail if this does not throw any exception
} catch(MyException e) { // only catch the exception you expect,
// otherwise you may catch an exception for a dependency unexpectedly
// a strong assertion on the message,
// in case the exception comes from anywhere an unexpected line of code,
// especially important if your checking IllegalArgumentExceptions
assertEquals("the message I get", e.getMessage());
}
人によってはassertTrue少し強いかもしれないので、assertThat(e.getMessage(), containsString("the message");好ましいかもしれません。
@Test
void testFooThrowsIndexOutOfBoundsException() {
IndexOutOfBoundsException exception = expectThrows(IndexOutOfBoundsException.class, foo::doStuff);
assertEquals("some message", exception.getMessage());
}
http://junit.org/junit5/docs/current/user-guide/#writing-tests-assertionsの JUnit 5 に関する詳細情報
JUnit には、「expected」属性を使用して、これに対するサポートが組み込まれています。
次のようなソリューションが必要な場合:
これが私が書いたユーティリティ関数です：
public final <T extends Throwable> T expectException( Class<T> exceptionClass, Runnable runnable )
{
try
{
runnable.run();
}
catch( Throwable throwable )
{
if( throwable instanceof AssertionError && throwable.getCause() != null )
throwable = throwable.getCause(); //allows testing for "assert x != null : new IllegalArgumentException();"
assert exceptionClass.isInstance( throwable ) : throwable; //exception of the wrong kind was thrown.
assert throwable.getClass() == exceptionClass : throwable; //exception thrown was a subclass, but not the exact class, expected.
@SuppressWarnings( "unchecked" )
T result = (T)throwable;
return result;
}
assert false; //expected exception was not thrown.
return null; //to keep the compiler happy.
}
(ブログより引用)
次のように使用します。
@Test
public void testMyFunction()
{
RuntimeException e = expectException( RuntimeException.class, () ->
{
myFunction();
} );
assert e.getMessage().equals( "I haz fail!" );
}
public void myFunction()
{
throw new RuntimeException( "I haz fail!" );
}
私の場合、db から常に RuntimeException を取得しますが、メッセージは異なります。そして、例外はそれぞれ処理する必要があります。これが私がそれをテストした方法です：
@Test
public void testThrowsExceptionWhenWrongSku() {
// Given
String articleSimpleSku = "999-999";
int amountOfTransactions = 1;
Exception exception = null;
// When
try {
createNInboundTransactionsForSku(amountOfTransactions, articleSimpleSku);
} catch (RuntimeException e) {
exception = e;
}
// Then
shouldValidateThrowsExceptionWithMessage(exception, MESSAGE_NON_EXISTENT_SKU);
}
private void shouldValidateThrowsExceptionWithMessage(final Exception e, final String message) {
assertNotNull(e);
assertTrue(e.getMessage().contains(message));
}
例外を返さなければならないメソッドの後にアサーションの失敗を使用できます。
try{
methodThatThrowMyException();
Assert.fail("MyException is not thrown !");
} catch (final Exception exception) {
// Verify if the thrown exception is instance of MyException, otherwise throws an assert failure
assertTrue(exception instanceof MyException, "An exception other than MyException is thrown !");
// In case of verifying the error message
MyException myException = (MyException) exception;
assertEquals("EXPECTED ERROR MESSAGE", myException.getMessage());
}
次のように、オンとオフを切り替えることができる Matcher を作成するだけです。
public class ExceptionMatcher extends BaseMatcher<Throwable> {
private boolean active = true;
private Class<? extends Throwable> throwable;
public ExceptionMatcher(Class<? extends Throwable> throwable) {
this.throwable = throwable;
}
public void on() {
this.active = true;
}
public void off() {
this.active = false;
}
@Override
public boolean matches(Object object) {
return active && throwable.isAssignableFrom(object.getClass());
}
@Override
public void describeTo(Description description) {
description.appendText("not the covered exception type");
}
}
使用するには:
を追加public ExpectedException exception = ExpectedException.none();してから:
ExceptionMatcher exMatch = new ExceptionMatcher(MyException.class);
exception.expect(exMatch);
someObject.somethingThatThrowsMyException();
exMatch.off();
Java8 を使用した Junit4 ソリューションは、この関数を使用することです。
public Throwable assertThrows(Class<? extends Throwable> expectedException, java.util.concurrent.Callable<?> funky) {
try {
funky.call();
} catch (Throwable e) {
if (expectedException.isInstance(e)) {
return e;
}
throw new AssertionError(
String.format("Expected [%s] to be thrown, but was [%s]", expectedException, e));
}
throw new AssertionError(
String.format("Expected [%s] to be thrown, but nothing was thrown.", expectedException));
}
使用法は次のとおりです。
assertThrows(ValidationException.class,
() -> finalObject.checkSomething(null));
唯一の制限はfinal、ラムダ式でオブジェクト参照を使用することであることに注意してください。このソリューションにより、ソリューションを使用してメソッド レベルで thhowable を期待する代わりに、テスト アサーションを続行できます@Test(expected = IndexOutOfBoundsException.class)。
たとえば、以下のコード フラグメントに対して Junit を記述したいとします。
public int divideByZeroDemo(int a,int b){
return a/b;
}
public void exceptionWithMessage(String [] arr){
throw new ArrayIndexOutOfBoundsException("Array is out of bound");
}
上記のコードは、発生する可能性のある未知の例外をテストするためのものであり、以下のコードは、カスタム メッセージで何らかの例外をアサートするためのものです。
@Rule
public ExpectedException exception=ExpectedException.none();
private Demo demo;
@Before
public void setup(){
demo=new Demo();
}
@Test(expected=ArithmeticException.class)
public void testIfItThrowsAnyException() {
demo.divideByZeroDemo(5, 0);
}
@Test
public void testExceptionWithMessage(){
exception.expectMessage("Array is out of bound");
exception.expect(ArrayIndexOutOfBoundsException.class);
demo.exceptionWithMessage(new String[]{"This","is","a","demo"});
}
@Test(expectedException=IndexOutOfBoundsException.class)
public void testFooThrowsIndexOutOfBoundsException() throws Exception {
doThrow(IndexOutOfBoundsException.class).when(foo).doStuff();
try {
foo.doStuff();
} catch (IndexOutOfBoundsException e) {
assertEquals(IndexOutOfBoundsException .class, ex.getCause().getClass());
throw e;
}
}
メソッドが正しい例外をスローしたかどうかを確認する別の方法を次に示します。
この問題に対する私の解決策についてコメントしたいと思いました。これにより、例外に関連する JUnit コードが不要になりました。
assertTrue(boolean) を try/catch と組み合わせて使用して、スローされると予想される例外を探しました。次に例を示します。
public void testConstructor() {
boolean expectedExceptionThrown;
try {
// Call constructor with bad arguments
double a = 1;
double b = 2;
double c = a + b; // In my example, this is an invalid option for c
new Triangle(a, b, c);
expectedExceptionThrown = false; // because it successfully constructed the object
}
catch(IllegalArgumentException e) {
expectedExceptionThrown = true; // because I'm in this catch block
}
catch(Exception e) {
expectedExceptionThrown = false; // because it threw an exception but not the one expected
}
assertTrue(expectedExceptionThrown);
}