Java 8ではこれがはるかに簡単になり、Kotlin / Scalaでは二重になっています。
少しユーティリティクラスを書くことができます
class MyAssertions{
public static void assertDoesNotThrow(FailingRunnable action){
try{
action.run()
}
catch(Exception ex){
throw new Error("expected action not to throw, but it did!", ex)
}
}
}
@FunctionalInterface interface FailingRunnable { void run() throws Exception }
そしてあなたのコードは単純になります：
@Test
public void foo(){
MyAssertions.assertDoesNotThrow(() -> {
//execute code that you expect not to throw Exceptions.
}
}
Java-8にアクセスできない場合は、痛々しいほど古いJava機能を使用します。任意のコードブロックと簡単なコメントです。
//setup
Component component = new Component();
//act
configure(component);
//assert
/*assert does not throw*/{
component.doSomething();
}
そして最後に、kotlinを使用して、最近好きになった言語は次のとおりです。
fun (() -> Any?).shouldNotThrow()
= try { invoke() } catch (ex : Exception){ throw Error("expected not to throw!", ex) }
@Test fun `when foo happens should not throw`(){
//...
{ /*code that shouldn't throw*/ }.shouldNotThrow()
}
あなたがこれをどのように表現したいかをいじくる余地はたくさんありますが、私は常に流暢な主張のファンでした。
について
あなたはこれに間違った方法で取り組んでいます。機能をテストするだけです。例外がスローされた場合、テストは自動的に失敗します。例外がスローされない場合、テストはすべて緑色になります。
これは原則として正しいですが、結論としては正しくありません。
Javaでは、制御フローの例外を許可しています。これはDouble.parseDouble、a NumberFormatExceptionやPaths.getを介したAPIなどのJREランタイム自体によって行われますInvalidPathException。
Double.ParseDouble多分正規表現、多分手書きのパーサー、または倍精度浮動小数点数の範囲を特定の何かに制限する他のドメインルールを埋め込むものを使用して、の数値文字列を検証するコンポーネントを作成した場合、これをテストする最善の方法成分？明らかなテストは、結果の文字列が解析されたときに例外がスローされないことを主張することだと思います。上記assertDoesNotThrowまたは/*comment*/{code}ブロックのいずれかを使用して、そのテストを記述します。何かのようなもの
@Test public void given_validator_accepts_string_result_should_be_interpretable_by_doubleParseDouble(){
//setup
String input = "12.34E+26" //a string double with domain significance
//act
boolean isValid = component.validate(input)
//assert -- using the library 'assertJ', my personal favourite
assertThat(isValid).describedAs(input + " was considered valid by component").isTrue();
assertDoesNotThrow(() -> Double.parseDouble(input));
}
私はまた、上でこのテストをパラメータ化することをお勧めしますinput使用してTheoriesまたはParameterizedあなたがより簡単に他の入力のために、このテストを再利用できるようにします。または、エキゾチックなものにしたい場合は、テスト生成ツール（およびこれ）を使用できます。TestNGはパラメーター化されたテストをよりよくサポートしています。
私は特に嫌見つけることは使用しての勧告で@Test(expectedException=IllegalArgumentException.class)、この例外が危険なほど広いです。テスト対象のコンポーネントのコンストラクターのようにコードが変更されif(constructorArgument <= 0) throw IllegalArgumentException()、テストがその引数に0を提供していたのは便利であり、これは非常に一般的なことです。テストデータを適切に生成するのは驚くほど難しい問題です。何もテストしていなくても、緑色のバーになります。そのようなテストは役に立たないよりも悪いです。
