テストに導かれた成長するオブジェクト指向ソフトウェアを読んで、テストの分離とテストの脆弱性について学びました。各テストはコードまたは機能の一部に固有のものである必要があり、テストによるコード カバレッジの重複は最小限に抑える必要があるという考え。コードを変更するたびに 1 つのテストだけが壊れるという暗黙の理想。1 つの変更が原因であり、それがテストの変更によって修正されるかどうかを確認するために、複数の壊れたテストに時間を費やすことを避けます。
これは、単体テストには十分に簡単に思えますが、その性質上、非常に分離されています。ただし、統合テストによって示される場合、特に単体テストに加えて実行される場合、複数のテストが同じコード パスを実行することを避けるのは難しいようです。
私の質問は、統合テストを行うときにどの依存関係をモックする必要があるのですか? 何かを嘲笑する必要がありますか？単一の実行パスをテストし、このコード パスに直接関連しないすべての副作用をモックする必要がありますか?
ペアワイズ統合テストを行うというアイデアをいじっています。2 つのオブジェクト間の 1 つの関係をテストし、他のすべてをモックします。次に、これらのオブジェクトのいずれかの変更は、ペアによるエンドツーエンド テストの完全なチェーンを形成することに加えて、他の統合テストへの影響を最小限に抑える必要があります。
情報をありがとう..
編集：明確にするために、私は基本的に「通常の開発過程で多数の統合テストの失敗を回避するにはどうすればよいですか?」と尋ねています。これは、モックを使用することで達成されると思います。また、何をモックするかについて尋ねた理由。
更新: JBRainsberger による統合テストに関する非常に興味深い講演を見つけました。これは、おそらく少し物議をかもしているとしても、これにかなりよく答えていると思います。タイトルは「統合テストは詐欺です」なので、ご想像のとおり、彼は統合テスト (エンド ツー エンド タイプのテスト) をまったく提唱していません。議論は、統合テストは可能な相互作用を徹底的にテストするために必要な量を常にはるかに下回り(組み合わせ爆発による)、誤った信頼を与える可能性があるというものです. 代わりに、彼はコラボレーション テストとコントラクト テストと呼んでいるものを推奨しています。これは 90 分間の講演で、残念ながらホワイトボードはあまり明確ではなく、コード例もありません。そのため、まだ頭を悩ませています。分かりやすい説明ができたらここに書きます！他の誰かが私を打ち負かさない限り..
コントラクト テストの概要を次に示します。Design by Contract タイプのアサーションのように聞こえますが、これは C++ の非仮想インターフェイス パターンで実装できる/実装されると思います。
http://thecodewhisperer.tumblr.com/post/1325859246/in-brief-contract-tests
統合テストは詐欺のビデオ トークです: http://www.infoq.com/presentations/integration-tests-scam
概要：
統合テストは詐欺です。おそらく、徹底的にテストする必要がある統合テストの 2 ～ 5% を作成しているでしょう。おそらく、いたるところに単体テストを複製しているでしょう。統合テストは、おそらくあちこちで重複しています。統合テストが失敗した場合、何が壊れているのか誰にもわかりません。問題を解決する 2 つの攻撃 (コラボレーション テストとコントラクト テスト) を学びます。