0

ネストされた関数呼び出しのシナリオでのモック テストに関して、概念的に深刻な問題があります。プロジェクトで JUnit と Mockito を使用しています。次の例で私の問題を説明しましょう:-

public class ClassA {
        public void methodOne(param1, param2, param3, param4) {
            // do something

            String temp = methodTwo(param2, param3, param4);

            // do something
        }

        public String methodTwo(param2, param3, param4) {
            // do something

            return methodThree(param2, param3) + methodFour(param4);
        }

        public String methodThree(param2, param3) {
            // do something
            return param2.get(0).getIndex + ":" + param3.getPosition();
        }

        public String methodFour(param4) {
            // do something

            return param4.getDetail() + "|" + param4.getCount();
        }
    }

methodThree()やのような基本的なメソッドをテストするmethodFour()必要がある場合は、(テスト対象の関数の実行をサポートするために) 必要なスタブを使用して必要なパラメーターのモックを作成し、その後で実行と検証 (状態/動作) を行うことができます。

しかしmethodTwo()、別のユニットとしてすでにテストされている他の関数へのネストされた呼び出しを持つ のようなメソッドはどうですか。モック オブジェクトを に渡すmethodTwo()と、それらはネストされたメソッドに渡され、NullPointerException()これらのモックはネストされた関数呼び出しの必要性に従ってスタブ化されていないため、与えられます。確かに、ネストされた呼び出しでもスムーズな実行をサポートするためにモックに追加のスタブを追加できますが、明らかにこれは健全なアプローチではありません。このスタブ化の負担は、methodOne()またはその他のような大規模なメソッドに移行するにつれてさらに悪化します。

単体テストに関する限り、テスト対象の単体以外の単体については気にしません。どこが間違っているのかを教えてください。また、単体テストと模擬テストのより良い/適切な方法を提案してください。ありがとう。

4

1 に答える 1

1

ここでの私の考えは、どのような動作を行うべきかという点でmethodOne、methodTwoそれぞれが何らかの仕様を満たしているということです。同じクラスの他のメソッドへの呼び出しを介してこれらのそれぞれを実装することを選択したという事実は関係ありません。それらの動作が正しいことをテストする必要があります。したがって、テストを書くときは実装を見ないでください。代わりに、仕様を見てください。

もちろん、私のアドバイスを無視することを選択した場合は、いつでも Mockito スパイを使用して、他のメソッドをテストしている間にいくつかのメソッドをスタブ化できます。しかし、真剣に、しないでください。

于 2013-08-01T09:19:00.743 に答える