テスト中の文

Question

私は、一般的にカスタム電子メールメッセージの作成を制御する単体テストの集合を持つParametrizedテストクラスを持っています。今のクラスは、パラメータ化されたクラスで使用される因子に依存する多くのテストを持っています。テストの流れはすべてのテストで同じです。テストの例：

@Test 
public void testRecipientsCount() { 
    assertEquals(3, recipientsCount); 
} 

は、私は受信者のリストにいくつかの余分な内部の電子メールを追加私の電子メールクラスに余分なfuncionalityを追加する必要がありました、それが唯一の例いくつかのために起こり、それは私の問題につながります。

私は作成されたメッセージの量を表明したいと言います。古いテストの場合は、それぞれのケースで同じでしたが、今の場合によって異なります。

@Test 
public void testRecipientsCount(){ 
    if(something) { 
     assertEquals(3, recipientsCount); 
    } 
    else { 
     assertEquals(4, recipientsCount); 
    } 
} 
... 

が、私より経験豊富な同僚たちはテストクラスでIFSを避ける​​べきであると言う（と私はちょっとそれに同意）：私にとって最も直感的な方法は、if文を追加することでした。

私は、2つのテストのclassessで分割テストがうまくいくかもしれないと思っていましたが、それは両方のクラスで冗長なコードにつながります（私はまだ非永遠のメッセージが作成されたかどうかチェックしなければなりません。そのうちの1つに数行追加されました。

私はこれをどうやって行うのですか？冗長コード（パラメータ化されていないクラスを使用しないと、より冗長なコードを生成する場合）を使用しないでください。

Answer 1

私の意見では、Junitはプロトコルのように読むべきです。 これは、テストケースをより読みやすくするために冗長なコードを書くことができることを意味します。 ビジネスロジックとネガティブケースの可能な各if文のテストケースを記述します。それは100％テストカバレッジを取得する唯一の方法です。 私は構造を使用します。それはあなたのコードの複雑さを軽減し、あなたがが利用できるようにしている

abstract class YourBusinessObjectAssert{ 
    public static void assertYourBussinessObjectIsValid(YourBusinessObject pYourBusinessObject,  Collection<YourBusinessObject> pAllYourBusinessObject) { 
for (YourBusinessObject lYourBusinessObject : pAllYourBusinessObject) { 
    if (lYourBusinessObject.isTechnicalEqual(pYourBusinessObject)) { 
    return; 
    } 
} 
assertFalse("Could not find requested YourBusinessObject in List<YourBusinessObject>!", true); 
} 
} 

：

- testdata preparation 
- executing logic 
- check results 
- clear data 

さらにあなたは複合体が自身の抽象クラスで、大きなオブジェクトのアサート書くべきを他の開発者。

Answer 2

単体テストは、私の意見では、可能であれば1つしか試してはいけません。 if文が必要な場合は、if/elseコードの各ブロックに対して1つ以上の単体テストが必要になるでしょう。

私はテストが物語のように読むべきでしょうね可能であれば - 私の好みのレイアウト（およびそのない私の考え:-) - そのかなり広く使われている）である：

- given: do setup etc 
- when: the place you actually execute/call the thing under test 
- expect: verify the result 

ユニットのもう一つの利点テストのテストは、障害が発生したときにその原因が明確になった場合に発生する可能性があります。長いテストで多くの結果が得られれば、テストが失敗した理由を説明するのがずっと難しくなります。

Answer 3

なぜ、各メソッドに共通することをテストするプライベートメソッドはありませんか？ （おそらくtestCommonStuff()方法のためのいくつかの入力パラメータを持つ）ような何か：あなたは冗長なコードを取得しないと、あなたは小さなテストにテストを分割することができ

@Test 
public void testRecipientsCountA(){ 
    testCommonStuff(); 
    // Assert stuff for test A 
} 

@Test 
public void testRecipientsCountB(){ 
    testCommonStuff(); 
    // Assert stuff for test B 
} 

private void testCommonStuff() { 
    // Assert common stuff 
} 

この方法です。また、実際に同じものをテストする必要がある場合は、テストのエラーが起こりにくくなります。どのテストが失敗したかはまだ分かりますので、トレーサビリティは問題ありません。

Answer 4

パラメータ化されたテストで、あなたがしていることをきちんとやり遂げることが可能かどうかはわかりません。一部のフィーチャのパラメータに基づいて異なるテストケースの動作が必要な場合は、パラメータが設定されていない別のテストクラスでこれらのフィーチャを別々にテストする方がよい場合があります。

本当にパラメータ化テストクラスのすべてを維持したいならば、単純な主張として、あなたの例のテストは、少なくとも読み取るように、私は、ヘルパー関数を作るために傾くことになります。

@Test 
public void testRecipientsCount(){ 
    assertEquals(expectedCount(something), recipientsCount) 
} 

private int expectedCount(boolean which) { 
    if (something){ 
     return 3; 
    } 
    else { 
     return 4; 
    } 
}