Mockitoスーパークラスのメソッドの呼び出しのみをモックする方法

一部のテストでMockitoを使用しています。

次のクラスがあります。

class BaseService {  
    public void save() {...}  
}

public Childservice extends BaseService {  
    public void save(){  
        //some code  
        super.save();
    }  
}   

の2番目の呼び出し（super.save）のみをモックしたいChildService。最初の呼び出しは、実際のメソッドを呼び出す必要があります。それを行う方法はありますか？

いいえ、Mockitoはこれをサポートしていません。

これはあなたが探している答えではないかもしれませんが、あなたが見ているのは、設計原理を適用しないことの症状です：

継承よりも構成を優先する

スーパークラスを拡張する代わりに戦略を抽出すると、問題はなくなります。

ただし、コードを変更することは許可されていませんが、とにかくコードをテストする必要がある場合、この厄介な方法で、まだ希望があります。一部のAOPツール（AspectJなど）を使用すると、コードをスーパークラスメソッドに組み込み、その実行を完全に回避できます（残念ながら）。プロキシを使用している場合、これは機能しません。バイトコード変更（ロード時ウィービングまたはコンパイル時ウィービング）を使用する必要があります。PowerMockやPowerMockitoなど、この種のトリックをサポートするモックフレームワークもあります。

私はリファクタリングに行くことをお勧めしますが、それが選択肢でない場合は、いくつかの深刻なハッキングを楽しむことができます。

リファクタリングの選択肢がない場合は、スーパーメソッド呼び出しですべてをモック/スタブできます。

    class BaseService {

        public void validate(){
            fail(" I must not be called");
        }

        public void save(){
            //Save method of super will still be called.
            validate();
        }
    }

    class ChildService extends BaseService{

        public void load(){}

        public void save(){
            super.save();
            load();
        }
    }

    @Test
    public void testSave() {
        ChildService classToTest = Mockito.spy(new ChildService());

        // Prevent/stub logic in super.save()
        Mockito.doNothing().when((BaseService)classToTest).validate();

        // When
        classToTest.save();

        // Then
        verify(classToTest).load();
    }

ChildService.save（）メソッドから別のメソッドにコードをリファクタリングし、ChildService.save（）をテストする代わりに新しいメソッドをテストすることを検討してください。これにより、スーパーメソッドへの不要な呼び出しを回避できます。

例：

class BaseService {  
    public void save() {...}  
}

public Childservice extends BaseService {  
    public void save(){  
        newMethod();    
        super.save();
    }
    public void newMethod(){
       //some codes
    }
} 

スーパークラスメソッドを呼び出すサブクラスでパッケージ保護（同じパッケージのテストクラスを想定）メソッドを作成し、オーバーライドされたサブクラスメソッドでそのメソッドを呼び出します。次に、スパイパターンを使用して、テストでこのメソッドに期待値を設定できます。かなりではありませんが、テストでスーパーメソッドのすべての期待設定を処理する必要があるよりは確かに優れています。

iweinの応答に完全に同意したとしても（

継承よりも構成を優先する

）、ときどき継承が自然に見える場合があることを認め、ユニットテストのためだけにそれを壊したりリファクタリングしたりしません。

だから、私の提案：

/**
 * BaseService is now an asbtract class encapsulating 
 * some common logic callable by child implementations
 */
abstract class BaseService {  
    protected void commonSave() {
        // Put your common work here
    }

    abstract void save();
}

public ChildService extends BaseService {  
    public void save() {
        // Put your child specific work here
        // ...

        this.commonSave();
    }  
}

そして、単体テストでは：

    ChildService childSrv = Mockito.mock(ChildService.class, Mockito.CALLS_REAL_METHODS);

    Mockito.doAnswer(new Answer<Void>() {
        @Override
        public Boolean answer(InvocationOnMock invocation)
                throws Throwable {
            // Put your mocked behavior of BaseService.commonSave() here
            return null;
        }
    }).when(childSrv).commonSave();

    childSrv.save();

    Mockito.verify(childSrv, Mockito.times(1)).commonSave();

    // Put any other assertions to check child specific work is done

その理由は、基本クラスが公開されていないため、可視性のためにMockitoがそれをインターセプトできないためです。基本クラスをパブリックとして変更するか、サブクラスの@Override（パブリックとして）を変更すると、Mockitoはそれを正しくモックできます。

public class BaseService{
  public boolean foo(){
    return true;
  }
}

public ChildService extends BaseService{
}

@Test
@Mock ChildService childService;
public void testSave() {
  Mockito.when(childService.foo()).thenReturn(false);

  // When
  assertFalse(childService.foo());
}

継承が理にかなっている場合、おそらく最も簡単なオプションは、スーパーを呼び出す新しいメソッド（パッケージprivate ??）を作成し（それをsuperFindallと呼びましょう）、実際のインスタンスをスパイしてから、モックしたい方法でsuperFindAll（）メソッドをモックすることです。親クラス1。カバレッジと可視性の点で完璧なソリューションではありませんが、それで十分であり、簡単に適用できます。

 public Childservice extends BaseService {
    public void save(){
        //some code
        superSave();
    }

    void superSave(){
        super.save();
    }
}