これは素晴らしい質問です！根本的な原因は、ユニットテストだけでなくJUnitを使用していることにあると思います。したがって、質問は分割する必要があります。
- 統合(またはその他の単体テストよりも高度なテスト) テストで Mockito.verify() を使用する必要がありますか?
- ブラックボックスの単体テストで Mockito.verify() を使用する必要がありますか?
- ホワイトボックスの単体テストで Mockito.verify() を使用する必要がありますか?
したがって、単体テストよりも高いテストを無視する場合、質問は言い換えることができます。「単体テストと、これに使用する経験則」.
それでは、このすべてを段階的に見ていきましょう。
*-統合(または他の単体テストよりも高度なテスト) テストで Mockito.verify() を使用する必要がありますか?* 答えは明らかにノーだと思います。さらに、これにモックを使用するべきではありません。テストは、実際のアプリケーションにできるだけ近づける必要があります。アプリケーションの分離された部分ではなく、完全なユースケースをテストしています。
*ブラックボックスとホワイトボックスのユニットテスト*ブラックボックスアプローチを使用している場合、実際に何をしているのか、(すべての等価クラス) 入力、状態、および期待される出力を受け取るテストを提供します。このアプローチでは、一般的にモックを使用することは正当化されます (モックが正しいことを行っていることを模倣するだけです。テストする必要はありません) が、Mockito.verify() の呼び出しは不要です。
ホワイトボックスアプローチを使用している場合、実際に行っていることは、ユニットの動作をテストしていることになります。このアプローチでは、Mockito.verify() の呼び出しが不可欠です。ユニットが期待どおりに動作することを確認する必要があります。
グレーボックステストの経験則
ホワイトボックステストの問題点は、結合度が高くなることです。考えられる解決策の 1 つは、ホワイト ボックス テストではなく、グレー ボックス テストを行うことです。これは、ブラックボックステストとホワイトボックステストを組み合わせたようなものです。ホワイト ボックス テストのようにユニットの動作を実際にテストしていますが、一般的には可能な場合は実装に依存しないようにします。可能であれば、ブラックボックスの場合のようにチェックを行い、出力が期待どおりであることをアサートします。したがって、あなたの質問の本質は、それが可能な場合です。
これは本当に大変です。良い例はありませんが、例を挙げてみましょう。上記の equals() と equalsIgnoreCase() の場合、Mockito.verify() を呼び出すべきではなく、出力をアサートするだけです。できなかった場合は、できるようになるまでコードを小さな単位に分解します。一方、@Service があり、@Service の基本的なラッパーである @Web-Service を書いているとします。これは、すべての呼び出しを @Service に委任します (そして、追加のエラー処理を行います)。この場合、Mockito.verify() の呼び出しが不可欠です。@Serive に対して行ったすべてのチェックを複製しないでください。正しいパラメーター リストを使用して @Service を呼び出していることを確認するだけで十分です。