0

Mockito を使用した JUnit テストは初めてです。「テストロジック」の問題を理解するのに苦労しています。その1つは、stub の深さです。

簡単な例を挙げましょう。

まず、これがテスト対象のクラスであると仮定しましょう。

Class ToBeTested {
    public int a1() {}
    public int a2() {}
    public int a3() {}

    public int A() {
        return a1() + a2() + a3();
    }

    public int B() {
        temp = A();
        return temp++;
    }
}

JUnit テストを作成しようとすると、これらのメソッドをスタブ化する方法がわかりません。例えば：

@Test
public void testB() {
    ToBeTested mockedTBT = mock(ToBeTested.class);

    /*
     *Problem here: How Deep to stub?
     */

    //shallow stubbing
    BDDMockito.given(mockedTBT.A()).willReturn(6);

    //deep stubbing
    BDDMockito.given(mockedTBT.a1()).willReturn(1);
    BDDMockito.given(mockedTBT.a2()).willReturn(2);
    BDDMockito.given(mockedTBT.a3()).willReturn(3);

    int expected = 7;
    int result= mockedTBT.B();

    assertEquals(expected, result);
}

この場合、浅いスタブまたは深いスタブを使用する必要がありますか? または、合理的なテストを作成するための規則に従うことはできますか?

よろしくお願いいたします。

4

2 に答える 2

2

注目している動作をテストするために必要な最小限のモックを作成する必要があります。

B()上記の例では、インクリメントされた値を呼び出しA()て返すことを気にしているようです。したがって、 からの応答をモックするだけA()です。

後で の機能をテストしたいA()場合があります。その場合は、呼び出す他のメソッドをモックすることを選択できますA()。

于 2013-07-16T14:51:49.177 に答える
2

本当に単体テストを行っているのであれば、理想的には、テスト対象のクラス (テスト対象のシステム) でメソッドをスタブしないでください。むしろ、共同作業者クラスをモックするだけです。あなたの場合、これはおそらく、クラスを複数のクラスに分割し、それぞれが明確に定義された一連の責任を持ちたいことを示す「コードの匂い」を示唆しています。

クラスを分割する必要がないと思われる場合は、単体テストのためにそれをブラックボックスとして扱い、可能なすべての異なる種類の入力条件を考慮して、それを外部呼び出しからあなたの内部の部分を嘲笑するのではなく、クラス。私はMockito とモッキングが大好きですが、使用する場所には正しい場所と間違った場所があります。

于 2013-07-16T15:20:53.213 に答える