（なぜ）単体テストが依存関係をテストしないことが重要ですか？

自動化されたテストの価値を理解し、問題が十分に特定されていて、良いテストケースを思いつくことができる場所ならどこでもそれを使用します。ただし、こことStackOverflowの一部の人々は、依存関係ではなくユニットのみをテストすることを強調していることに気付きました。ここでは、利益が見られません。

テストの依存関係を回避するためのモッキング/スタブ化は、テストを複雑にします。実稼働コードに人為的な柔軟性/デカップリング要件を追加して、モックをサポートします。（これは良いデザインを促進すると言う人には賛成できません。余分なコードを書いたり、依存性注入フレームワークのようなものを導入したり、コードベースに複雑さを加えて実際のユースケースなしで物事をより柔軟/プラグ可能/拡張可能/分離することは、オーバーエンジニアリングではなく、良いデザイン。）

第二に、依存関係のテストとは、どこでも使用される重要な低レベルコードが、テストを明示的に考えた人以外の入力でテストされることを意味します。依存する低レベルの機能をモックアウトせずに、高レベルの機能で単体テストを実行することで、低レベルの機能に多くのバグを発見しました。理想的には、これらは低レベル機能の単体テストで発見されたはずですが、見逃されたケースは常に発生します。

これの反対側は何ですか？単体テストが依存関係もテストしないことは本当に重要ですか？もしそうなら、なぜですか？

編集：データベース、ネットワーク、Webサービスなどの外部依存関係のモックの価値を理解できます（これを明確にする動機付けをしてくれたAnna Learに感謝します）。内部依存関係、つまり他のクラス、静的関数などに言及していました。直接的な外部依存関係はありません。

定義の問題です。依存関係のあるテストは、単体テストではなく統合テストです。統合テストスイートも必要です。違いは、統合テストスイートが別のテストフレームワークで実行される可能性があり、おそらく時間がかかるためビルドの一部としてではない可能性があることです。

製品の場合：ユニットテストはビルドごとに実行され、数秒かかります。統合テストのサブセットは、チェックインごとに実行され、10分かかります。完全な統合スイートは毎晩実行され、4時間かかります。

すべての依存関係を適切にテストすることは依然として重要ですが、ジェフリーファウストが言ったように、それは統合テストの領域にあります。

単体テストの最も重要な側面の1つは、テストを信頼できるものにすることです。合格したテストが本当に良いことを意味し、失敗したテストが実際に本番コードの問題を意味することを信用しない場合、テストは可能な限り有用ではありません。

テストを信頼できるものにするためには、いくつかのことを行う必要がありますが、この回答では1つだけに焦点を当てます。もし開発者のすべてが簡単にコードをチェックインする前にそれらを実行できるように、彼らは実行しやすいことを確認する必要があります。「簡単に実行することは、」あなたのテストはすぐに実行することを意味し、それらを行かせるために必要な一切の広範な構成や設定がありません。理想的には、誰でもコードの最新バージョンをチェックアウトし、すぐにテストを実行し、合格することを確認できるはずです。

他のもの（ファイルシステム、データベース、Webサービスなど）への依存関係を抽象化することで、構成の必要性を回避でき、あなたや他の開発者は「ああ、テストは失敗したから」と言いたくなる状況になりにくくなりますネットワーク共有を設定します。まあ、後で実行します。」

一部のデータを使用して何を行うかをテストする場合、そのビジネスロジックコードの単体テストでは、そのデータの取得方法を考慮する必要はありません。データベースなどのサポートに依存せずにアプリケーションのコアロジックをテストできることは素晴らしいことです。あなたがそれをしていないなら、あなたは逃しています。

PSテスト可能性という名目でオーバーエンジニアリングすることは間違いなく可能であると付け加えます。アプリケーションのテスト駆動は、それを軽減するのに役立ちます。しかし、いずれにしても、アプローチの実装が不十分であっても、アプローチの有効性が低下することはありません。「なぜ私はこれをしているのですか？」開発中。

public class MyClass 
{
    private SomeClass someClass;
    public MyClass()
    {
        someClass = new SomeClass();
    }

    // use someClass in some way
}

私は通常、どのようSomeClassに作成されるかを気にしません。使いたいだけです。SomeClassが変更され、コンストラクターへのパラメーターが必要になった場合、それは私の問題ではありません。これに対応するためにMyClassを変更する必要はないはずです。

さて、それは設計部分に触れているだけです。単体テストに関する限り、他のクラスからも自分を守りたいと思っています。MyClassをテストする場合、外部依存関係がないこと、SomeClassがデータベース接続または他の外部リンクを導入していないことを知っているのが好きです。

しかし、さらに大きな問題は、メソッドの結果の一部がSomeClassのメソッドの出力に依存していることも知っていることです。SomeClassをモック/スタブ化せずに、その入力を需要に応じて変更する方法がないかもしれません。運が良ければ、SomeClassから正しい応答をトリガーするようにテスト内で環境を構成できるかもしれませんが、そのようにすると、テストが複雑になり、テストが脆弱になります。

MyClassを書き換えてコンストラクターでSomeClassのインスタンスを受け入れると、（モックフレームワークまたは手動モックを使用して）必要な値を返すSomeClassの偽のインスタンスを作成できます。私は、一般的にはありません持っている。この場合、インタフェースを導入します。そうするかどうかは、多くの点で選択する言語によって決定される個人的な選択です（たとえば、インターフェイスはC＃でより可能性が高いですが、Rubyでは間違いなく必要ではありません）。

単体テストと統合テストの問題は別として、次のことを考慮してください。

クラスウィジェットは、クラスThingamajigおよびWhatsItに依存しています。

ウィジェットの単体テストが失敗します。

どのクラスに問題がありますか？

「デバッガを起動する」または「コードが見つかるまでコードを読む」と回答した場合、依存関係ではなくユニットのみをテストすることの重要性を理解しています。

プログラミングは料理のようなものだと想像してください。単体テストは、材料が新鮮でおいしいことを確認することと同じです。一方、統合テストは、食事がおいしいことを確認するようなものです。

最終的には、食事がおいしいこと（またはシステムが機能すること）を確認することが最も重要なことであり、究極の目標です。しかし、もしあなたの材料、つまりユニットが機能していれば、もっと安い方法で見つけることができます。

実際、ユニット/メソッドが機能することを保証できれば、システムが機能している可能性が高くなります。「確実」ではなく「可能性が高い」ことを強調します。あなたはまだあなたが調理した食事を味わい、最終製品が良いことを伝えるために誰かが必要であるのと同じように、あなたはまだ統合テストが必要です。新鮮な食材を使って簡単に到着できます。それだけです。

ユニットを完全に分離してテストすることで、このユニットが送信できるデータと状況のすべての可能なバリエーションをテストできます。残りから隔離されているため、テスト対象のユニットに直接影響を与えないバリエーションは無視できます。これにより、テストの複雑さが大幅に軽減されます。

さまざまなレベルの依存関係を統合したテストにより、単体テストではテストされなかった可能性のある特定のシナリオをテストできます。

両方が重要です。単体テストを実行するだけで、コンポーネントを統合するときに常により複雑な微妙なエラーが発生します。統合テストを行うということは、マシンの個々の部品がテストされていないという自信なしにシステムをテストしていることを意味します。エントリの組み合わせの数を追加するコンポーネントが非常に高速になり（要因的と考えてください）、十分なカバレッジでテストを作成することが非常に迅速に不可能になるため、統合テストを行うだけでより良い完全なテストを達成できると考えることはほとんど不可能です。

要するに、ほとんどすべてのプロジェクトで通常使用する3つのレベルの「単体テスト」です。

• モックまたはスタブ化された依存関係で分離され、単一のコンポーネントの地獄をテストする単体テスト。理想的には、完全なカバレッジを試みます。
• より微妙なエラーをテストする統合テスト。制限ケースと典型的な条件を示す、慎重に作成されたスポットチェック。多くの場合、完全なカバレッジは不可能であり、システムが故障する原因に焦点を当てています。
• システムにさまざまな実際のデータを注入し、データを計測し（可能な場合）、出力を観察して仕様とビジネスルールに準拠していることを確認する仕様テスト。

依存性注入は、システムを複雑にすることなく、ユニットテスト用のコンポーネントを非常に簡単に分離できるため、これを達成するための非常に効率的な手段の1つです。あなたのビジネスシナリオはインジェクションメカニズムの使用を保証しないかもしれませんが、あなたのテストシナリオはほとんどそうです。私にとってはこれで十分です。これらを使用して、部分統合テストを介してさまざまな抽象化レベルを個別にテストすることもできます。

これの反対側は何ですか？単体テストが依存関係もテストしないことは本当に重要ですか？もしそうなら、なぜですか？

単位。単数を意味します。

2つのことをテストするということは、2つのこととすべての機能的な依存関係があることを意味します。

3つ目を追加すると、テストの機能的な依存関係が直線的に増加します。モノ間の相互接続は、モノの数よりも速く成長します。

テスト対象のn個のアイテムには、n（n-1）/ 2の潜在的な依存関係があります。

それが大きな理由です。

シンプルさには価値があります。

最初に再帰を学んだことを覚えていますか？私の教授は、「xを実行するメソッドがあると仮定します」（たとえば、xのfibbonacciを解く）と言いました。「xを解くには、x-1およびx-2のメソッドを呼び出す必要があります」。同様に、依存関係をスタブアウトすることで、依存関係が存在するふりをして、現在のユニットが実行すべきことをテストできます。もちろん、依存関係を厳密にテストしていることを前提としています。

これは本質的には作業中のSRPです。テストに対しても単一の責任に焦点を合わせると、必要なメンタルジャグリングの量がなくなります。

（これは小さな答えです。ヒントをありがとう@TimWilliscroft。）

障害は、次の場合に簡単にローカライズできます。

• テスト対象ユニットとその依存関係の両方が、個別にテストされます。
• 各テストは、テストの対象となるコードに障害がある場合にのみ失敗します。

これは紙の上でうまく機能します。ただし、OPの説明に示されているように（依存関係にはバグがあります）、依存関係がテストされていない場合、障害の場所を特定するのは困難です。

たくさんの良い答え。他にもいくつかのポイントを追加します。

単体テストでは、依存関係が存在しないときにコードをテストすることもできます。たとえば、あなた、またはあなたのチームは、まだ他のレイヤーを書いていないか、別の会社が提供するインターフェースを待っているかもしれません。

ユニットテストは、開発マシンに完全な環境（データベース、Webサーバーなど）を用意する必要がないことも意味します。私は強く、すべての開発者がいることをお勧めしません何らかの理由でそれが本番環境を模倣することができない場合には、それはREPROバグのためには、伐採しかし、このような環境を持っているなどしかし、その後、ユニットテストは、少なくとも湯にいくつかのレベルを提供しますより大きなテストシステムに入る前に、コードに自信を持ってください。

設計の側面について：コードをテスト可能にすることは、小さなプロジェクトでもメリットがあると思います。必ずしもGuiceのようなものを導入する必要はありません（単純なファクトリクラスでよく行われます）が、構築プロセスをプログラミングロジックから分離すると、

• インターフェースを介してすべてのクラスの依存関係を明確に文書化する（チームに新しい人にとって非常に役立つ）
• クラスがより明確になり、保守が容易になります（いオブジェクトグラフの作成を別のクラスにすると）
• 疎結合（変更をはるかに容易にする）

ええと、これらの回答に記載されている単体テストと統合テストには良い点があります！

ここで、コスト関連の実用的な見方を逃しています。それは、非常に孤立した/原子単体テスト（互いに非常に独立している可能性があり、データベース、ファイルシステムなどのような依存関係なしでそれらを並行して実行するオプションがあります）と（より高いレベルの）統合テストの利点を明確に見ると言いましたしかし...それはコスト（時間、お金など）とリスクの問題でもあります。

私の経験から「テスト方法」を考える前に、もっと重要な他の要因（「テストするもの」など）があります...

顧客は（暗黙的に）余分な量のテストの作成と保守に料金を支払いますか？よりテスト駆動型のアプローチ（コードを書く前に最初にテストを書く）が私の環境（コード障害のリスク/コスト分析、人、設計仕様、テスト環境のセットアップ）で本当にコスト効率が良いですか？コードには常にバグがありますが、テストを実稼働環境に移行する方が費用対効果が高いでしょうか（最悪の場合！）？

また、コードの品質（標準）が何であるか、フレームワーク、IDE、設計原則などに大きく依存します。あなたとあなたのチームが従うもの、およびそれらがどの程度経験されているかです。よく書かれた、理解しやすく、十分に文書化された（理想的には自己文書化）モジュール式のコードは、逆の場合よりもバグが少ない可能性があります。したがって、広範なテストの実際の「必要性」、プレッシャー、または全体的なメンテナンス/バグ修正コスト/リスクは高くない場合があります。

私のチームの同僚が提案した極端な話をしましょう。データベース内のすべてのクラスとモックを作成するために、純粋なJava EEモデルレイヤーコードを希望する100％のカバレッジで単体テストする必要があります。または、統合テストをすべての可能な現実世界のユースケースとWeb UIワークフローの100％でカバーすることを希望するマネージャーは、ユースケースが失敗するリスクを冒したくないためです。しかし、約100万ユーロという厳しい予算があり、すべてをコーディングするかなり厳しい計画があります。潜在的なアプリのバグが人間や企業にとって非常に大きな危険ではない顧客環境。私たちのアプリは、（一部の）重要な単体テスト、統合テスト、設計されたテスト計画による主要な顧客テスト、テスト段階などで内部テストされます。一部の原子力工場や医薬品製造向けのアプリは開発していません！

私自身は、可能であればテストを作成し、コードの単体テスト中に開発しようとします。しかし、私はしばしばトップダウンのアプローチ（統合テスト）からそれを行い、重要なテスト（多くの場合モデルレイヤーで）の「アプリレイヤーカット」を行う良いポイントを見つけようとします。（多くの場合、「レイヤー」についてです）

さらに、ユニットと統合テストのコードは、時間、お金、メンテナンス、コーディングなどにマイナスの影響を与えません。クールで適用する必要がありますが、多くの開発されたテストの開始時または5年後の影響を慎重に検討してくださいコード。

ですから、信頼やコスト/リスク/利益の評価に大きく依存していると言えます。現実の世界のように、たくさんの、または100％の安全メカニズムで走り回ったり、走り回ったりしたくないようなものです。

子供はどこかに登ることができ、また登る必要があり、転倒して怪我をする可能性があります。間違った燃料を入れたため、車が動作しなくなる可能性があります（無効な入力:)）。タイムボタンが3年後に機能しなくなった場合、トーストが燃えることがあります。しかし、私は高速道路で運転したり、取り外したステアリングホイールを手にしたくはありません。