モックオブジェクトを使用するとき、ユニットテストで依存関係の問題をどのように検出しますか？

クラスXがあり、動作X1を検証する単体テストを作成します。Xを依存関係とするクラスAもあります。

Aの単体テストを作成するとき、Xをモックします。つまり、Aの単体テスト中に、Xのモックの動作をX1に設定（仮定）します。時間が経ち、人々はあなたのシステムを使用し、変更を必要とし、Xは進化します。Xを変更して動作X2を表示します。明らかに、Xの単体テストは失敗し、それらを調整する必要があります。

しかし、Aではどうでしょうか？Aの単体テストは、Xの動作が変更されても失敗しません（Xのモックにより）。「実際の」（変更された）Xで実行すると、Aの結果が異なることを検出する方法は？

「それは単体テストの目的ではない」という線に沿った答えを期待していますが、単体テストにはどのような価値がありますか？すべてのテストに合格したときに、重大な変更が導入されていないことを本当に伝えているだけですか？そして、あるクラスの振る舞いが（喜んでまたは不本意で）変化するとき、どのようにすべての結果を（できれば自動化された方法で）検出できますか？統合テストにもっと集中すべきではないでしょうか？

Aの単体テストを記述するとき、Xをモックします。

あなたは？絶対に必要でない限り、私はしません。私がしなければならない：

1. X 遅い、または
2. X 副作用があります

これらのどちらも当てはまらない場合、私のユニットAテストXもテストします。他のことをするということは、隔離テストを非論理的な極端なものにすることです。

コードの他の部分のモックを使用してコードの部分がある場合、私は同意します：そのような単体テストのポイントは何ですか？だからこれをしないでください。それらのテストが実際の依存関係を使用するようにしてください。そうすることで、はるかに価値のあるテストが形成されます。

そして、これらのテストを「ユニットテスト」と呼ぶことに怒っている人がいる場合は、単に「自動テスト」と呼び、優れた自動テストの作成に取り掛かります。

両方が必要です。各ユニットの動作を検証するユニットテスト、およびそれらが正しく接続されていることを確認するためのいくつかの統合テスト。統合テストのみに依存することの問題は、すべてのユニット間の相互作用に起因する組み合わせの爆発です。

クラスAがあり、すべてのパスを完全にカバーするには10個のユニットテストが必要だとします。次に、別のクラスBがあります。このクラスBでは、コードが通過できるすべてのパスをカバーするために10個の単体テストも必要です。アプリケーションで、Aの出力をBにフィードする必要があるとします。これで、コードはAの入力からBの出力までの100の異なるパスを取ることができます。

単体テストでは、すべてのケースを完全にカバーするために、20個の単体テストと1つの統合テストのみが必要です。

統合テストでは、すべてのコードパスをカバーする100のテストが必要になります。

JB Rainsberger Integrated Tests Are A Scam HDのみの統合テストに依存することのマイナス面に関する非常に良いビデオがあります

Aの単体テストを作成するとき、Xをモックします。つまり、Aの単体テスト中に、Xのモックの動作をX1に設定（仮定）します。時間が経ち、人々はあなたのシステムを使用し、変更を必要とし、Xは進化します。Xを変更して動作X2を表示します。明らかに、Xの単体テストは失敗し、それらを調整する必要があります。

ちょっと待って。Xが失敗したことをテストすることの意味はあまりにも重要なので、そのように見直すことはできません。

Xの実装をX1からX2に変更すると、Xの単体テストが壊れる場合、コントラクトXに後方互換性のない変更を加えたことを示します。

X2はでは、Xはないリスコフの感覚あなたがしなければならないので、考えて、あなたの利害関係者のニーズを満たすための他の方法（新しい仕様Yを導入するように、それはX2で実装されている）について。

より深い洞察については、Pieter Hinjens：ソフトウェアバージョンの終わり、またはRich Hickey Simple Made Easyを参照してください。

Aの観点からは、協力者が契約Xを尊重するという前提条件があります。また、事実、Aの分離テストでは、AがX契約に違反する協力者を認識するという保証はありません。

統合テストのレビューは詐欺です。高レベルでは、X2がコントラクトXを正しく実装するために必要な数の隔離されたテストと、Xから興味深い応答が与えられてAが正しいことを行うために必要な数の隔離されたテストが必要です。X2とAがXの意味に同意することを確認するための少数の統合テスト。

この区別は、単独テスト対sociableテストとして表されることがあります。Jay Fields が単体テストで効果的に動作するを参照してください。

統合テストにもっと集中すべきではないでしょうか？

繰り返しますが、統合テストは詐欺です-Rainsbergerは、統合（スペルチェック）テストに依存しているプロジェクトに（経験上）一般的な正のフィードバックループについて詳しく説明しています。要約すると、設計にプレッシャーをかける独立した/孤立したテストがないと、品質が低下し、より多くの間違いとより統合されたテストにつながります。

また、（一部の）統合テストも必要になります。複数のモジュールによって導入される複雑さに加えて、これらのテストの実行は、孤立したテストよりも多くの抵抗を伴う傾向があります。作業の進行中に非常に高速なチェックを繰り返し実行する方が効率的であり、「完了」したと思われる場合の追加チェックを保存します。

まず、質問の核となる前提に欠陥があると言ってみましょう。

実装をテスト（またはモック）することはなく、インターフェイスをテスト（およびモック）します。

インターフェイスX1を実装する実際のクラスXがある場合、X1にも準拠するモックXMを作成できます。それから、私のクラスAは、クラスXまたはモックXMのいずれかであるX1を実装するものを使用する必要があります。

ここで、Xを変更して新しいインターフェイスX2を実装するとします。まあ、明らかに私のコードはもはやコンパイルされません。AにはX1を実装し、もはや存在しないものが必要です。この問題は特定されており、修正できます。

X1を置き換える代わりに、変更するだけです。これでクラスAがすべて設定されました。ただし、モックXMはインターフェースX1を実装しなくなりました。この問題は特定されており、修正できます。

単体テストとモックの基本は、インターフェイスを使用するコードを書くことです。インターフェイスのコンシューマーは、コードがどのように実装されるかを気にせず、同じコントラクトが（入力/出力）に準拠していることのみを気にします。

メソッドに副作用がある場合、これは破綻しますが、「ユニットテストやモックはできません」として安全に除外できると思います。

質問を順番に受け取ります：

単体テストにはどのような価値がありますか

書いて実行するのは安価で、早期のフィードバックが得られます。Xを壊すと、適切なテストがあればすぐにわかります。すべてのレイヤーをユニットテストしない限り（データベース上でも）、統合テストの作成を検討しないでください。

すべてのテストに合格したときに、重大な変更が導入されていないことを伝えるだけです。

テストに合格しても、実際にはほとんどわかりません。十分なテストを書いていない可能性があります。十分なシナリオをテストしていない可能性があります。ここではコードカバレッジが役立ちますが、それは特効薬ではありません。常に合格するテストがあるかもしれません。したがって、赤はしばしば見落とされがちな赤、緑、リファクタリングの最初のステップです。

そして、あるクラスの振る舞いが（喜んでまたは不本意で）変化するとき、どのようにすべての結果を（できれば自動化された方法で）検出できますか

より多くのテスト-ツールはどんどん良くなっていますが。ただし、インターフェイスでクラスの動作を定義する必要があります（以下を参照）。注意：テストピラミッドの上部には、手動テストの場所が常にあります。

統合テストにもっと集中すべきではないでしょうか？

さらに多くの統合テストも答えではなく、作成、実行、保守に費用がかかります。ビルドのセットアップに応じて、ビルドマネージャーはそれらを除外し、覚えている開発者に頼るようにします（決して良いことではありません！）。

開発者は、優れた単体テストがあれば5分で発見した壊れた統合テストを修正しようとして何時間も費やしているのを見てきました。これに失敗したら、ソフトウェアを実行してみてください-それはエンドユーザーが気にするすべてです。ユーザーがスイート全体を実行したときにカードの家全体が倒れた場合に合格する百万個のユニットテストがあるという点はありません。

クラスAが同じ方法でクラスXを消費することを確認したい場合は、コンクリートではなくインターフェイスを使用する必要があります。その後、重大な変更がコンパイル時に選択される可能性が高くなります。

そのとおりです。

ユニットテストは、ユニットの分離された機能をテストするためにあります。これは、意図したとおりに動作し、愚かなエラーが含まれていないことを一目で確認します。

単体テストは、アプリケーション全体が機能することをテストするためのものではありません。

多くの人が忘れているのは、ユニットテストがコードを検証する最も速くて汚い手段であるということです。小さなルーチンが機能することがわかったら、統合テストも実行する必要があります。単体テストは、テストなしよりもわずかに優れています。

単体テストがある理由は、それらが安価であるはずだからです。作成、実行、および保守が迅速です。それらを最小統合テストに変え始めると、あなたは苦痛の世界に入ります。同様に、完全な統合テストを行って、単体テストをすべて無視することもできます。

現在、一部の人々は、ユニットはクラス内の単なる機能ではなく、クラス全体（自分自身を含む）であると考えています。ただし、これはユニットのサイズを大きくするだけなので、必要な統合テストは少なくなりますが、それでも必要です。完全な統合テストスイートなしでは、プログラムが想定どおりに機能することを検証することはまだ不可能です。

さらに、ライブ（またはセミライブ）システムで完全な統合テストを実行して、顧客が使用する条件で機能することを確認する必要があります。

単体テストは、何かの正しさを証明しません。これはすべてのテストに当てはまります。通常、ユニットテストは、契約ベースの設計（契約による設計は別の言い方です）と、正当性を定期的に検証する必要がある場合は自動化された正当性証明と組み合わされます。

クラス不変条件、前提条件、および事後条件で構成される実際の契約がある場合、下位コンポーネントの契約に上位コンポーネントの正当性を基づいて、階層的に正当性を証明することができます。これは、契約による設計の背後にある基本概念です。

ひどくed笑されたテストはほとんど役に立たないと思います。ほとんどの場合、元のクラスがすでに持っている振る舞いを再実装することになり、モックの目的を完全に無効にします。

私にとってより良い戦略は、懸念事項を適切に分離することです（たとえば、パートBからZを持ち込むことなく、アプリのパートAをテストできます）。このような優れたアーキテクチャは、優れたテストの作成に役立ちます。

また、副作用をロールバックできる限り、喜んで受け入れます。たとえば、私のメソッドがdb内のデータを変更する場合は、許可しましょう。データベースを以前の状態にロールバックできる限り、何が害になりますか？また、データが期待どおりに見えるかどうかをテストで確認できるという利点もあります。インメモリDBまたは特定のdbのテストバージョンは、ここで本当に役立ちます（例：RavenDBsインメモリテストバージョン）。

最後に、サービスの境界でモックをするのが好きです。たとえば、サービスbに対してそのhttp呼び出しを行わないが、インターセプトして適切なものを導入しましょう

両方の陣営の人々が、クラステストと行動テストが直交していないことを理解してほしい。

クラステストとユニットテストは同じ意味で使用されますが、使用しないでください。一部の単体テストは、クラスで実装されることがあります。以上です。ユニットテストは、クラスのない言語で何十年もの間行われてきました。

テスト動作については、GWT構造を使用してクラステスト内でこれを行うことは完全に可能です。

さらに、自動化されたテストがクラスに沿って進むか動作に沿って進むかは、むしろ優先度に依存します。あるものは迅速にプロトタイプを作成してドアから取り出す必要があり、あるものはインハウススタイルによるカバレッジの制約があります。多くの理由。どちらも完全に有効なアプローチです。あなたはあなたのお金を支払い、あなたはあなたの選択を取ります。

だから、コードが壊れたときにどうするか。インターフェースにコーディングされている場合、結石だけを変更する必要があります（すべてのテストと一緒に）。

ただし、新しい動作を導入しても、システムを危険にさらす必要はありません。Linuxなどには、非推奨の機能がたくさんあります。そして、コンストラクター（およびメソッド）のようなものは、すべての呼び出しコードを強制的に変更せずに喜んでオーバーロードできます。

クラステストが成功するのは、まだ時間の制約、複雑さなどが原因で、まだ組み込まれていないクラスに変更を加える必要がある場合です。包括的なテストがある場合、クラスを開始するのは非常に簡単です。

Xのインターフェースが変更されない限り、Aに関連するものは何も変更されていないため、Aの単体テストを変更する必要はありません。XとAの単体テストを実際に書いたようですが、Aの単体テストと呼んでいるようです。

Aの単体テストを作成するとき、Xをモックします。つまり、Aの単体テスト中に、Xのモックの動作をX1に設定（仮定）します。

理想的には、Xのモックは、Xに期待する動作だけでなく、Xの考えられるすべての動作をシミュレートする必要があります。そのため、インターフェイス自体を変更する以外に、Xを変更しても、Aの単体テストに影響はありません。

例：Aがソートアルゴリズムであり、Aがソートするデータを提供するとします。Xのモックは、null戻り値、空のデータリスト、単一要素、複数の要素が既にソート済み、複数の要素がまだソートされていない、複数の要素が後方にソートされている、同じ要素が繰り返されているリスト、null値が混在している、とんでもない多数の要素があり、例外もスローする必要があります。

したがって、Xは最初に月曜日にソートされたデータを返し、火曜日に空のリストを返しました。しかし、Xが月曜日にソートされていないデータを返し、火曜日に例外をスローする場合、Aは気にしません。これらのシナリオはすでにAの単体テストでカバーされています。

さまざまなテストを検討する必要があります。

単体テスト自体はXのみをテストします。Xの動作を変更することはできませんが、システム全体を保護することはできません。動作の変更を導入することなく、クラスをリファクタリングできるようにします。そして、Xを壊すと、それを壊してしまいます...

モックとのユニットテストとテストのためにすべきで実際に模擬Xは、あなたがそれを変更した後も渡しておく必要があります。

しかし、テストには複数のレベルがあります！統合テストもあります。これらのテストは、クラス間の相互作用を検証するためにあります。これらのテストは、すべてにモックを使用しないため、通常は価格が高くなります。たとえば、統合テストは実際にレコードをデータベースに書き込む場合があり、単体テストには外部依存関係がないようにします。

また、Xに新しい動作が必要な場合、望ましい結果を提供する新しいメソッドを提供する方が良いでしょう。