インターフェイスのプロバイダーは、テスト用のモック実装も提供する必要がありますか？

単体テストで発見されたはずのバグについて、前回の統合テストで多くの時間を無駄にしました。問題は、呼び出したインターフェイス/サービスが予期したとおりに動作せず、ユニットテストがこの問題を見つけられなかったということでした。ユニットテストのためにそのインターフェイスをモックしたため、モックは当然、インターフェイスが何を間違って解釈するかに基づいていました。行う。インターフェイスの説明/仕様（簡潔なJavaDocコメント）があいまいであり、私たちの誤解の原因となったため、今では、インターフェイスを提供してくれた親愛なる同僚に少し怒る可能性があります。一方、同じ同僚がインターフェースのモック実装を提供してユニットテストで呼び出すことができれば、問題は回避できると思いました。

さて、共有インターフェースを提供して使用するチーム間でモックオブジェクトの作成を整理する上でのベストプラクティスは何でしょうか。あなたの経験は何ですか？

理想的には、はい。

他の人が使用するコードを書く人は、コードを補完するものを提供する義務はありません。しかし、もしあなたが実施例を含むことができる- -人々はあなたのコードを使用するように（と誰もが常にこの考え方を書くべきである）、広範な関連文書を希望している、非常に便利。

私はこれまでにドキュメントを読んだことはなく、「これはばかげている。ドキュメントが多すぎる方法だ」と思ったことはありません。人々は当然のことながら、不要だと思うものを飛ばすことに才能があります。ただし、説明されていないドキュメントや概念を単純に読んで補間することはできません。したがって、仮定しても安全です。優れたドキュメントが多すぎるということはありません。また、初心者の幼児としてそれを読む人（つまり、できるだけ単純にする）を想定している必要があります。

クラスをインスタンス化して使用する方法の例は常に役立ちます。ただし、コードがドキュメントに依存しすぎて理解できない場合、それは別の（個別の）問題です。

この答えは、同僚に怒鳴ることを正当化する火力と見なすべきではありません。これは、私が有益であり、実行する必要があると思うことのガイドラインにすぎません。これはあなたの状況ではまったく役に立ちませんが（私はあなたの質問は基本的には怒りだと思いますが）、次にできる最善のことは、模範を示し、同僚がやって来ることを願っています。

インターフェイスのプロバイダーは、テスト用のモック実装も提供する必要がありますか？

いいえ。ただし、プロバイダーはユニットテストのソースコードも提供する必要があります。これらの単体テストを読むと、ライブラリの使用方法がよくわかります。プロバイダーに期待することを指定するために、プロバイダーテストにユニットテストを追加できます。

偽物/スタブ/モックを実装できるモックツール/フレームワークは数多くあります。

偽の実装のどの部分が実際の実装とほぼ同一である必要があり、どの部分が単なるファサードであるかを知ることができないため、モック実装をプロバイダーに依頼することは、コストと利益の関係がよくありません。

これを回避するもう1つの方法は、プロバイダーがコード契約を使用して、指定された方法でlibが使用されていることを確認することです。