2012-05-05 6 views
3

私は、処理の特定の時点で一定の不変量が保持されることを期待する方法があります。
コード処理中のポイントXで、変数highと変数lowが割り切れる必要があります。
だからコードで私が行いますJUnitを使用する場合、AssertionErrorsは禁止されていますか?

if(high % low != 0){ 
    throw new AssertionError("Invalid state of low and high [low = "+ low+ ", high=" + high+"]"); 
} 

JUnitsとのユニットテストの間、私はこれをテストするためのテストケースを持っていました。

try { 
//At this point I know for sure that the low and high are not divible so process() should throw an Assertion Error 
    process(); 
    fail(); 
} 
catch(AssertionError e){   
} 

をしかし、テストケースは緑色であった:
だから私はやりました!
しかし、私はjunitがfailのアサートエラーを起こしていることに気がつきましたが、その結果、テストケースが失敗した代わりにパスされました。
私の見解では、私のコードで発生させる適切なエラーはAssertionErrorであり、いくつかは一般的ではありません。 IllegalArgumentsException
テストケースが機能するようにこれを修正する方法がありますか、最初のコードでAssertionErrorを使用しないでください。このような場合は、どのような例外を提起する必要がありますか?

答えて

1
​​

しかし、条件が不変であるならば、それは常に真でなければ、とてAssertionErrorは、このように投げてはいけません、あなたは、このようにしてもユニットテスト、それにできないようにする必要があり。あなたがそれをテストすることができれば、それは不変量が実際には不変ではなく、与えられた呼び出しの順番または与えられた引数によって真であるかもしれないことを意味します。したがって、AssertionErrorよりもIllegalStateExcetionを優先する必要があります。

+0

+1。私は不変量に関する議論に従わない。あなたは本当に提供された議論(しかし、間接的に、 ''高 ''と低 ''が引き渡された引数から導出されます)に依存しています、そして、常に高値と低値が割り切れるべきであるという事実は、これは不変量としてそれらを構成しないのですか? – Cratylus

+0

不変量は、クラス自体によって常に真であることが保証されているブール条件です。提供された引数が正しい場合にのみこの条件が満たされる場合、それはもはや不変式ではありません。それを不変にする方法は、不変条件を偽にするなら、引数を拒否することです。不正な引数を拒否するには、IllegalArgumentExceptionをスローします。例えば、Personクラスは、「年齢> 0」のようにivariantを持つことができます。 setAge(int age)メソッドは、年齢が<= 0の場合にIllegalArgumentExceptionをスローすることでこの不変量を保証する必要があります。 –

+0

これは良い解決策です。ここには2つの選択肢があります:(#1)AssertionErrorの代わりに別の例外を投げます。必要に応じて、独自の例外クラスを作成します。 (#2)私はブロックをキャッチする例外メッセージintを最もよくチェックします:assertEquals( "低および高[低= 2、高= 11]の無効な状態"、e.getMessage()) –

2

ユニットテストではtry-catchブロックを使用しないでください。あなたは例外がアノテーションを使用が予想される場合:JUnitのは、内部AssertionErrorを使用しているため

@Test(expected=Exception.class) 
public void youTestMethod() { 
    ... 
} 

あなたは、このようなIllegalArgumentsExceptionとして別の例外を使用する必要があります。私はIllegalArgumentsExceptionが実際に何が間違っていたかをより詳しく説明しています。

+0

私のバージョンのJUnit(4.10)では、java.lang.AssertionErrorをスローします。 –

+0

あなたは正しいです、なぜ彼らはそれをしたのだろうか。ここでアノテーションを使用することに同意しますか? –

+0

いいえ、私はAssertionErrorの使用には同意しません。私の答えとそのコメントを見てください。 –

0
> should I not be using the AssertionError in my code in the first place? 

ませ JUnitのテストが失敗したJUnitのランナーを伝えるためにAssertionErrorが、そのファミリー・ツリーを使用していません。はい、そこにあなたのコードとJUnitとの間に矛盾があるが、それはだ、私はIllegalArgumentsExceptionのように、一般的なExceptoinのいずれかを使用するか、自分の例外

0

を作成します

> If this is the case, what exception should I be raising? 

(Simmilarは、.NET NUnitのランナーに適用されます)周りを回るのは簡単です。

JUnitテストケースを作成すると、既に推測したように、テストケースが失敗したときにAssertionErrorがスローされます。

あなたのテストケースが合格したことをJUnitに知らせるためには、テストコードは他の例外/エラーに対してもAssertionErrorを投げてはいけません。

A. -

2つのテストケース(少なくとも)があります高値と低値が正確に割り切れる - テストケースコードはAssertionErrorをスローしない。

ここで、テストケースが正しく動作する場合、AssertionErrorは存在せず、JUnitはそれを知っています。

B.高値と低値が正確に割り切れるわけではありません。コードでAssertionErrorが発生するはずですが、テストケースは発生しません。

boolean failed; 
try { 
    //test case setup 
    yourClass.callYourMethod(4,2); 
    failed = true; 
} catch (AssertionError e) { 
    failed = false; 
} 
if (failed) { 
    fail(); 
} 
関連する問題