junit - 模擬テストの代わりに実際のテストを行う方法（結果を変更する）

Question

私は以下のテストケースを書いていますが、これは良いテストであれば少し混乱します。なぜなら、私がuserDataMockを擬似すると、本当の結果を変えていると言えるからです。だから私はすでに最終結果を "期待"に変更しています。だから私は実際のテストを行うときに、私はすでにそれを嘲笑しているので、それが可能な唯一の結果は "期待"ですMockito.when(userDataMock.doStandardLogin(loginInfoMock)).thenReturn(expected); これまでは開発者がこれをやっているのを見たことがありますが、何が間違っているのか考えていないのですか？

public class DoStandardLoginUsecaseTest { 

    private DoStandardLoginUsecase target; 
    private MyApplication contextMock; 

    @Before 
    public void beforeEach() { 
     contextMock = Mockito.mock(MyApplication.class); 
     // Note that you need to mock the getPresenterComponent 
     // but I don't know what it returns. 
     target = new DoStandardLoginUsecase(contextMock); 
    } 

    @Test 
    public void buildUseCaseObservable() { 
     UserDataRepository userDataMock = Mockito.mock(UserDataRepository.class); 
     StandardLoginInfo loginInfoMock = Mockito.mock(StandardLoginInfo.class); 
     target.mUserDataRepo = userDataMock; 
     target.setLoginInfo(loginInfoMock); 

     Observable<Login> expected = // create your expected test data however you like... 
     Mockito.when(userDataMock.doStandardLogin(loginInfoMock)).thenReturn(expected); 
     Observable<Login> actual = target.buildUseCaseObservable(); 

     Assert.areSame(actual, expected); 
    } 

}

更新：

DoStandardLoginUsecase.java：

public class DoStandardLoginUsecase extends BaseUseCase { 

@Inject 
UserDataRepository mUserDataRepo; 

private StandardLoginInfo loginInfo; 

@Inject 
public DoStandardLoginUsecase(UserDataRepository userDataRepository) { 
mUserDataRepo = userDataRepository; 
} 

@Override 
public Observable<Login> buildUseCaseObservable() { 
    return mUserDataRepo.doStandardLogin(loginInfo); 
} 

public void setLoginInfo(StandardLoginInfo loginInfo) { 
    this.loginInfo = loginInfo; 
} 

}

Answer 1

これは、ここで私がテストをターゲットにしています実際のクラスがあります非常に健康的な考え、それは本当です - あなたがすべてを嘲笑するとき、あなたは最終的にあなたのテストをテストします。残念なことに今日の嘲笑は、ほとんどが悪用される非常に一般的な方法です。嘲笑するのではなく、さまざまな種類のテストを書くことができます。

• ユニットテストでは、クラスを個別にチェックします。これを嘲笑せずに可能にするには、特に古いOOPと豊かなモデルに従う必要があります。
• コンポーネント（a.k.a. integration）テスト - アプリの一部を初期化し、クラスのクラスターをチェックできます。たとえば、メモリ内DBを使用してスプリングコンテキストを初期化できます。
• 完全に配備されたアプリケーションに対してシステムテストが実行されます。それがUIの場合、これはセレンテストかもしれません。これがREST APIの場合、RestAssuredテストになる可能性があります。

これはTest Pyramidと呼ばれます。しかし、時にはあなたはまだ模擬したい。これは、通常、システムの境界で発生します。例えば。外部サイトからデータを取得し、結果を解析します。解析をチェックするために、外部サイトへの接続は本当に必要ではありません。データを取得する部分をモックすることができます。これにより、非常に高速で簡単なテストを書くことができます。