モックオブジェクトまたは統合テストの知識の重複と陳腐化の問題は良い

統合 テストと単体テストを選択する場合、多くのプログラマーは単体テスト（つまり、単体テスト）を好みます。 統合テストをアンチパターンと見なす人もいれば、単にファッションの傾向に従うだけの人もいます。 しかし、これが何につながるのか見てみましょう。 単体テストを実装するために、モックオブジェクトは外部サービスとデータストレージだけでなく、プログラム内に直接実装されたクラスにもハングアップします。 同時に、 模擬クラスが他のいくつかのクラスで使用されている場合、模擬オブジェクトはいくつかのクラスのテストに含まれます 。 また、テスト内でテスト済みの動作を設定するのが一般的であるため（ given-when-then 、 arrange-act-assert 、 テストビルダーを参照）、mokaの動作は毎回各テストで再度設定され、 DRY原則に違反します（コードの重複はないかもしれません） 。 さらに、クラスの動作はモックオブジェクトで宣言されますが、この宣言自体はチェックされないため、時間が経つにつれて、モックで宣言された動作は古くなり、モック対象のクラスの実際の動作とは異なる場合があります。 これは多くの困難を引き起こします：



1）まず、機能を変更するとき、クラスとそのテストに加えて、このクラスのmokeysも変更する必要があることを覚えるのは困難です。 TDDのフレームワーク内の開発サイクルを見てみましょう。「機能テストの作成\変更->機能の作成\変更->リファクタリング」。 モックオブジェクトはクラスの動作の宣言であり、これら3つのカテゴリのいずれにも関連していません（テストで使用されているにもかかわらず、機能テストではありません。機能自体もそうではありません）。 したがって、 プログラム内に実装されたクラスのモックオブジェクトを変更することは、TDDの概念に適合しません 。



2）次に、このクラスのすべての場所を見つけることは困難です。 このための単一のツールを見たことはありません。 ここでは、自転車を書くか、このクラスのすべての使用場所を見て、mokaが作成される場所を選択できます。 しかし、手動検索では、間違いを犯して何かを見落とす可能性があります。 ここで、おそらく質問があります。著者が説明しているように、問題が非常に根本的なものである場合、そのソリューションを簡素化するツールを実装することは誰にも起こりませんでしたか？ 私はこの主題について仮説を立てています。 数年前、IOCコンテナが通常のクラスを作成し、moksで説明されている動作のテストを自動的に作成および実行するように、モックオブジェクトを作成するはずのライブラリの作成を開始しました。 しかし、モックの問題に対するよりエレガントな解決策を見つけたので、このアイデアを放棄しました：この問題を作成しないだけです。 おそらく、同様の理由で、特定のクラスのmoxを検索するための特別なツールが実装されていないか、ほとんど知られていません。



3）第3に、クラスのモックを作成する場所はたくさんある可能性があり、それらをすべて変更することは日常的な作業です。 プログラマが自動化できないルーチンを実行することを余儀なくされた場合、これはツール、アーキテクチャ、またはワークフローに何か問題があることを明確に示しています。



問題の本質が明確であることを願っています。 次に、この問題を解決する方法を説明し、私の観点から、統合テストが単体テストよりも望ましい理由を説明します。









この問題の解決策として、外部サービスとデータウェアハウスに対してのみモックを使用することを提案します。他のケースでは、実際のクラスを使用します。 単体テストの代わりに統合テストを作成します。 一部のプログラマーは統合テストに懐疑的であり、この考えを好まないでしょう。



統合テストの反対者が与える議論を考えてみましょう。

ステートメント1.統合テストは、単体テストよりもエラーの検索にあまり役立ちません。

証明：

普遍的に使用されているクラスで、間違いがあったと想像してみましょう。 その後、クラス自体の直接のテストが赤に変わり、このクラスが使用されたすべての統合テストも赤になりました。 その結果、プロジェクトのテストの半分は赤です。 テストの発赤の理由は何ですか？ どのテストから始めますか？ しかし、クラスの代わりにモックオブジェクトが使用された場合、このクラスのテストのみが赤面します。

免責事項：

TDDのフレームワーク内のワークフローを思い出してみましょう。エラーを知らせる「赤」テスト->機能の作成/変更->「緑」テスト。 したがって、機能を変更する場合、プログラマは最初にテストを変更して、変更された機能をテストします。 コードにはまだ古い機能が含まれているため、テストは失敗します。 次に、プログラマーが機能コードを修正し、テストに合格します。 プログラマがクラスを操作したが、テストを操作しなかった場合、TDDのフレームワーク内で行動しませんでした。

しかし、プログラマーがコードを変更したが、テストを変更せず、進行状況を確認しなかった場合でも、テストのクラッシュは継続的統合サーバーによって追跡でき、バージョン管理システムへのプッシュごとにテストが自動的に実行されます。 変更の作成者には、テストの失敗に関するメッセージが表示され、ルールのクラスをすぐに覚え、最初にこれらの特定のクラスのテストの処理を開始します。 プログラマーが誤ってクラスにバグを導入し、それを修正した場合、このクラスのテストだけでなく、このクラスが使用されたすべてのテストも緑色になります。 しかし、緑色にならない場合はどうなりますか？ 次に、これは、クラスの変更がこのクラスが使用された他のクラスの動作の変更につながり、これらのクラスでエラーが発生したか、テストがアプリケーションロジックから逸​​脱したことを示すシグナルです。

別のケースも可能です。 何らかの理由でミスが行われたクラスがテストで十分にカバーされていなかった場合、mokasの単体テストでは問題がまったく明らかになりませんでした。 ただし、統合テストは少なくとも問題を通知しますが、問題のクラスを特定するには古き良きトレースに頼らなければなりません。

要約すると、TDDを使用する場合、変更していないクラスのテストを赤くすることは、問題を通知するため有利です。 TDDに従わずに継続的インテグレーションを使用する場合、「余分な」テストをやり直すことはそのような問題ではありません。 TDDに従わず、定期的にテストを実行しない場合、「落ちたテストは問題クラスです」という対応を特定する問題が関係します。 この場合、ユニットの代わりに統合テストを使用するのではなく、他の手段によって（mokaでの知識の重複とmokaで宣言された動作のテストの欠如の問題を解決する方が良いです（それらについては後で説明します）。

声明2.統合テストは、モジュール化よりも設計の助けが少ない

証明：

単体テストは、統合テストとは異なり、プログラマーがコンストラクターまたはプロパティを介して依存関係を注入することを強制します。 また、単体テストではなく統合テストを使用する場合、後輩はクラスコードで直接依存関係をインスタンス化できます。 しかし、私は建築ノートやレビューコードを書く時間はありません。 はい、誰も請求しません。 そして、私はしたくない。

免責事項：

実際、単体テストだけでプログラマに依存関係を強制することはできません。 IOC-containerはこれをうまく処理します。 実際、依存関係を注入する場合は、おそらくIOCコンテナーを使用しています。 もちろん、エントリポイントがあるメインクラス自体を作成するためのファクトリを作成できます。 しかし、IOCコンテナーは多くの一般的な問題を解決し、生活を簡素化します。 たとえば、シングルトンの実装の落とし穴を掘り下げることなく、クラスを1行のコードでシングルトンにすることができます。 したがって、依存関係を注入してもIOCコンテナーを使用しない場合は、これを開始することをお勧めします。

一般に、単体テストを使用する場合、ほぼ確実にIOCコンテナーを使用しています。 IOCコンテナーを使用する場合は、プログラマーが依存関係を挿入することをお勧めします。 もちろん、IOCコンテナーを使用せずにオブジェクトを作成できますが、単体テストを提供せずにクラスを作成できるのと同じです。 そのため、Inversion of control原則の実装を誘導するという点で、単体テストに大きな利点はありません。

さらに、アーキテクチャの制限のためにプログラマに必要なことを強制することはできませんが、依存関係の注入とIOCコンテナの使用の利点を説明するだけです。 他の暴力と同様に、力による強制は反抗を引き起こす可能性があります。

ステートメント3.テストで同じ機能をカバーするには、統合テストでは単体テストよりもはるかに多くのことが必要になります。

証明：

「Integration Tests-the lot of crooks」という大きなタイトルの記事の著者は、情熱を込めて統合テストを嫌い、それらを無限の痛みと苦しみをもたらすウイルスと見なしていると書いています。 彼は次のように自分の考えを実証しています。

完全な単体テストを作成できないため、統合テストを作成します。 この問題はおなじみです。すべてのテストに合格しましたが、プログラムに欠陥がまだ検出されています。 統合テストを作成して、プログラム実行パス全体が正常に機能することを確認することにします。 そして、「すべての場所で統合テストを使用してみましょう」と考えるまで、すべてが順調に進んでいるようです。 悪い考え！ プログラムを非線形的に実行する方法の数は、プログラムのサイズに依存します。 20ページのWebアプリケーションテストをカバーするには、少なくとも10,000のテストが必要です。 たぶん百万。 週に50個のテストを作成する場合、必要な量の2.5％である年間2,500個のテストのみを作成します。 そしてその後、なぜユーザーの呼び出しに70％の時間を費やすことに疑問を抱きますか？！ 統合テストは時間の無駄です。 それらは過去のままでなければなりません。

免責事項：

その記事の著者は、統合テストの次の定義を提供します。

統合テストという用語は、結果（成功または失敗）が複数の重要な動作の実装の正確さに依存するテストを意味します。

統合テストは、合格結果が複数の非自明なロジック（メソッド）の正しい実装に依存するテストです。

ご覧のとおり、この定義では、エントリポイントが配置されているメインクラスでのみ統合テストを記述できるという言葉はありませんが、上記の記事の著者は暗黙的にこの条件に基づいて推論しています。

TDDによると、テストはプログラムの実行方法ではなく、機能（機能）をテストするように設計されています。 TDDに従うと、この著者が話した問題に遭遇することはありません。 単体テストを作成するのと同じ方法で統合テストを作成しますが、プログラムに実装されたクラスをウェット処理しないでください。テストの数が指数関数的に増加するという問題は発生しません。

ステートメント4.統合テストは、単体テストよりも長く実行されます。

残念ながら、これについて議論することはできません-統合テストは、ほとんどの場合、単体テストよりも長く実行されます。 もちろん、mochaの作成は無料ではなく、時間がかかりますが、原則として、アプリケーションのロジックには時間がかかります。 仮に、テストが長期間不満足に実行される可能性が非常に高く、近い将来にテストされたロジックを最適化するつもりはありません。 そして論理的な解決策は、テストを最適化することです。 たとえば、mokの使用。

モカの知識の重複と陳腐化に対処する方法

最初の方法は、すでに述べたように、mokiを外部サービスとデータウェアハウスの動作を宣言するためにのみ使用することです。



2番目の方法は、mokaで宣言された動作の関連性を自動的にチェックすることです。 たとえば、適切なテストを自動的に作成して実行できます。 ただし、モックされるクラスには独自の依存関係があり、その一部は外部サービスである可能性があることを考慮する必要があります。 パフォーマンスのために、最初に最下位層のクラスの固有の動作（mokasで示される）をテストし、次に前のクラスを使用するクラスの動作などをテストできます。 次に、いくつかの同一の動作が複数の場所のmokasで宣言されている場合、一度だけチェックできます。

独自の湿潤ケースごとにテストを手動で作成し、mokaとテストの対応を何らかの方法で設定し、機能を変更するときにこの対応を手動で維持するようにプログラマーに指示できます。

モックオブジェクトの関連性を手動で維持するようにプログラマに指示するだけです。 ただし、従来のTDDから離れて、ワークフローをわずかに変更する必要があります。「機能のテストの変更->機能の変更-> ...」を「機能のテストの変更->この動作の宣言の変更（moksで）->機能の変更- > ... "。



モーキング中のコードの重複の問題を解消するために、すべてのmokiを1つのクラスに別のストレージに入れることができます。 これにより、「モックの動作宣言の変更」フェーズが簡素化されますが、ユニットテストの可読性が低下する可能性があります。その後、自分の優先順位に基づいて自分で決定します。

おわりに

マーティン・ファウラーは、古典的な学校とMoqists の2つの異なるTDD学校の設立に長い間気づいていました。

今、私は第2の二分法、つまり古典的なTDDとモック主義的なTDDの間の二分法を探求できる段階にいます。 ここでの大きな問題は、モック（または他のダブル）をいつ使用するかです。



古典的なTDDスタイルでは、可能であれば実際のオブジェクトを使用し、実際のオブジェクトを使用するのが難しい場合はdoubleを使用します。 したがって、従来のTDDerは、実際のウェアハウスとメールサービス用のダブルを使用します。 ダブルの種類はそれほど重要ではありません。



ただし、モックのTDD実践者は、興味深い動作を持つオブジェクトには常にモックを使用します。 この場合、倉庫とメールサービスの両方に対して。

これらの両方の学校には長所と短所があります。 個人的には、古典的なTDDの欠陥は、ウェットTDDの欠陥よりも受け入れられ、解決できると考えています。 さて、誰かがそれを逆に考えることができます-彼は湿式TDDを使用した結果に完全に対処でき、古典的なTDDで生じる問題を受け入れられるとは考えません。 どうして？ すべての人々は異なっており、誰もが自分のスタイルに対する権利を持っています。 個人的にクラシックが好きな理由を説明しましたが、最終的な選択はあなた次第です。



PSユニットテストを完全に放棄することはお勧めしません。 従来のTDDを使用する場合、他のクラスのメソッドとプロパティにアクセスしないクラスのテストはモジュール化されます。