単体テストの代わりに受け入れテストと統合テストを使用するだけで十分ですか？

この質問の簡単な紹介。私は現在TDDと最近BDDを1年以上使用しています。私は、モックなどの手法を使用して、テストをより効率的に記述します。最近、私は自分のために小さなお金管理プログラムを書くための個人的なプロジェクトを始めました。レガシーコードがなかったため、TDDから始めるのに最適なプロジェクトでした。残念ながら、TDDの喜びはあまり経験しませんでした。それは私の楽しみを台無しにし、プロジェクトをあきらめました。

なにが問題だったの？さて、TDDのようなアプローチを使用して、テスト/要件がプログラムの設計を進化させました。問題は、テストの作成/リファクタリングに関して、開発時間の半分以上がかかっていたことです。したがって、リファクタリングして多くのテストに書き込む必要があるため、最終的にはこれ以上機能を実装したくありませんでした。

職場では、レガシーコードがたくさんあります。ここでは、統合テストと受け入れテストを増やし、単体テストを減らしていきます。ほとんどのバグは受け入れテストと統合テストによって検出されるため、これは悪いアプローチではないようです。

私の考えは、最終的には単体テストよりも多くの統合テストと受け入れテストを書くことができるということでした。バグを検出するために言ったように、単体テストは統合/受け入れテストよりも優れていません。単体テストも設計に適しています。私はそれらの多くを書いていたので、私のクラスは常にテストしやすいように設計されています。さらに、テスト/要件が設計をガイドできるようにするアプローチは、ほとんどの場合、より良い設計につながります。単体テストの最後の利点は、高速であることです。ユニットテストとほぼ同じ速度で実行できることを知るために、十分な統合テストを作成しました。

ウェブを調べた後、私の考えによく似たアイデアがあちこちであることがわかりました。この考えをどう思いますか？

編集

質問には、デザインは良かったが、次の要件のために大規模なリファクタリングが必要な例の1つに答えました。

最初は、特定のコマンドを実行するためのいくつかの要件がありました。拡張可能なコマンドパーサーを作成しました。これは、ある種のコマンドプロンプトからコマンドを解析し、モデル上で正しいものを呼び出しました。結果は、ビューモデルクラスで表されました。

ここには何も問題はありませんでした。すべてのクラスは互いに独立しており、新しいコマンドを簡単に追加し、新しいデータを表示できました。

次の要件は、すべてのコマンドに独自のビュー表現（コマンドの結果の何らかのプレビュー）が必要であることです。新しい要件に対してより良い設計を実現するために、プログラムを再設計しました。

これは、すべてのコマンドに独自のビューモデルがあり、したがって独自のプレビューがあるためです。

問題は、コマンドパーサーがコマンドのトークンベースの解析を使用するように変更され、コマンドを実行する機能が削除されたことです。すべてのコマンドには独自のビューモデルがあり、データビューモデルは、表示する必要があるデータを知っている現在のコマンドビューモデルのみを知っています。

この時点で私が知りたかったのは、新しいデザインが既存の要件を満たさなかった場合のみです。受け入れテストを変更する必要はありませんでした。ほぼすべての単体テストをリファクタリングまたは削除する必要がありましたが、これは膨大な作業の山でした。

ここで見せたかったのは、開発中によく発生する一般的な状況です。古いデザインでも新しいデザインでも問題はありませんでした。要件に応じて自然に変更されただけでした。私がどう理解したか、これはTDDの利点の1つであり、デザインが進化します。

結論

すべての答えと議論をありがとう。この議論の要約として、次のプロジェクトでテストするアプローチを考えました。

• まず、いつものように何かを実装する前に、すべてのテストを作成します。
• 要件については、最初にプログラム全体をテストする受け入れテストをいくつか作成します。次に、要件を実装する必要があるコンポーネントの統合テストをいくつか作成します。この要件を実装するために別のコンポーネントと密接に連携するコンポーネントがある場合、両方のコンポーネントが一緒にテストされる統合テストも作成します。最後になりましたが、アルゴリズムまたは他のクラスを高い順列（シリアライザーなど）で記述する必要がある場合は、この特定のクラスの単体テストを記述します。他のすべてのクラスはテストされませんが、単体テストが行​​われます。
• バグについては、プロセスを簡素化できます。通常、バグは1つまたは2つのコンポーネントによって引き起こされます。この場合、バグをテストするコンポーネントの統合テストを1つ作成します。アルゴリズムに関連する場合は、ユニットテストのみを記述します。バグが発生したコンポーネントを簡単に検出できない場合、受け入れテストを作成してバグを特定します。これは例外です。

オレンジとリンゴを比較しています。

統合テスト、受け入れテスト、単体テスト、動作テスト-これらはすべてテストであり、すべてコードの改善に役立ちますが、それらもまったく異なります。

私は私の意見で異なるテストのそれぞれを調べて、うまくいけばそれらのすべてのブレンドが必要な理由を説明します：

統合テスト：

単純に、システムのさまざまなコンポーネント部分が正しく統合されていることをテストします。たとえば、Webサービスリクエストをシミュレートし、結果が返されることを確認します。私は通常、実際の（っぽい）静的データとモックされた依存関係を使用して、一貫して検証できるようにします。

受け入れテスト：

受け入れテストは、ビジネスユースケースと直接相関する必要があります。それは巨大（「取引が正しく送信された」）でも、小型（「リストを正常にフィルタリングするフィルター」）でも構いません-それは重要ではありません。重要なのは、特定のユーザー要件に明示的に関連付けられる必要があるということです。テスト駆動開発ではこれらに焦点を当てるのが好きです。というのは、devとqaが検証するためのユーザーストーリーに対するテストの優れたリファレンスマニュアルがあるからです。

単体テスト：

個々のユーザーストーリーを単独で構成する場合もしない場合もあります。たとえば、特定のWebページにアクセスするとすべての顧客を取得するというユーザーストーリーは、受け入れテスト（Webのヒットをシミュレートします）ページと応答の確認）が含まれる場合もありますが、いくつかの単体テスト（セキュリティ権限が確認されていること、データベース接続が正しくクエリされていること、結果の数を制限するコードが正しく実行されていることを確認します）-これらはすべて「単体テスト」ですそれは完全な受け入れテストではありません。

行動テスト：

特定の入力の場合、アプリケーションのフローがどうあるべきかを定義します。たとえば、「接続を確立できない場合、システムが接続を再試行することを確認します。」繰り返しますが、これは完全な受け入れテストになる可能性は低いですが、それでも有用な何かを検証することができます。

これらはすべて、テスト作成の多くの経験を通じて私の意見です。教科書のアプローチに焦点を当てるのは好きではありません-むしろ、テストに価値をもたらすものに焦点を当てます。

TL; DR：それがあなたのニーズを満たす限り、はい。

私は何年も前から受け入れテスト駆動開発（ATDD）開発を行ってきました。それは非常に成功する可能性があります。知っておくべきことがいくつかあります。

• ユニットテストは、IOCの実施に本当に役立ちます。単体テストがなければ、開発者は適切に作成されたコードの要件を満たしていることを確認する責任があります（単体テストが適切に作成されたコードを実行する限り）
• 通常はモックされているリソースを実際に使用している場合、速度が遅くなり、誤った障害が発生する場合があります。
• このテストでは、単体テストのように特定の問題を特定することはしません。テストの失敗を修正するには、さらに調査する必要があります。

今の利点

• テスト範囲が大幅に改善され、統合ポイントがカバーされます。
• システム全体が、ソフトウェア開発の全ポイントである受け入れ基準を満たしていることを確認します。
• 大規模なリファクタリングをはるかに簡単、高速、安価にします。

いつものように、分析を行い、このプラクティスがあなたの状況に適切かどうかを判断するのはあなた次第です。多くの人とは異なり、理想的な正しい答えはないと思います。それはあなたのニーズと要件に依存します。

さて、TDDのようなアプローチを使用して、テスト/要件がプログラムの設計を進化させました。問題は、テストの作成/リファクタリングに関して開発時間の半分以上がかかっていたことです

単体テストは、使用するコンポーネントのパブリックインターフェイスがあまり頻繁に変更されない場合に最適に機能します。これは、コンポーネントがすでに適切に設計されている場合（たとえば、SOLID原則に従って）を意味します。

したがって、コンポーネントで多くの単体テストを「スロー」することから「進化」するだけで良いデザインを信じることは誤りです。TDDは優れた設計の「教師」ではありません。設計の特定の側面が優れていること（特にテスト容易性）を検証するのに少しだけ役立ちます。

要件が変更され、コンポーネントの内部を変更する必要がある場合、これによりユニットテストの90％が中断されるため、非常に頻繁にリファクタリングする必要があり、デザインはおそらくあまり良くありませんでした。

したがって、私のアドバイスは次のとおりです。作成したコンポーネントの設計、およびオープン/クローズの原則に従ってコンポーネントをさらに作成する方法について考えてください。後者の考え方は、コンポーネントを変更せずに後でコンポーネントの機能を拡張できるようにすることです（したがって、ユニットテストで使用されるコンポーネントのAPIを壊すことはありません）。このようなコンポーネントは単体テストテストでカバーすることができます（カバーする必要があります）。また、経験はあなたが説明したほど苦痛ではありません。

そのような設計をすぐに思いつかない場合は、受け入れテストと統合テストの方が良いスタートになるかもしれません。

編集：コンポーネントの設計は問題ない場合もありますが、単体テストの設計が問題を引き起こす可能性があります。簡単な例：クラスXのメソッド "MyMethod"をテストして記述したい

    var x= new X();
    Assert.AreEqual("expected value 1" x.MyMethod("value 1"));
    Assert.AreEqual("expected value 2" x.MyMethod("value 2"));
    // ...
    Assert.AreEqual("expected value 500" x.MyMethod("value 500"));

（値には何らかの意味があると仮定します）。

さらに、実稼働コードではの呼び出しが1回だけであると想定しX.MyMethodます。現在、新しい要件のために、メソッド "MyMethod"には追加のパラメーター（例：などcontext）が必要ですが、これは省略できません。単体テストがなければ、呼び出しコードを1か所でリファクタリングする必要があります。単体テストでは、500箇所をリファクタリングする必要があります。

しかし、ここでの原因は単体テスト自体ではなく、「X.MyMethod」への同じ呼び出しが「Do n't Repeat Yourself（DRY）」の原則に厳密に従っていないという事実だけです。ここでは、テストデータと関連する期待値をリストに入れ、「MyMethod」の呼び出しをループで実行します（または、テストツールがいわゆる「データドライブテスト」をサポートしている場合、その機能を使用します）。メソッドシグネチャが1（500ではなく）に変更されたときにユニットテストで変更する場所の数。

実際の場合、状況はもっと複雑かもしれませんが、アイデアが得られることを願っています-ユニットテストで、変更される可能性があるかどうかわからないコンポーネントAPIを使用する場合は、必ず数を減らしてくださいそのAPIの呼び出しの最小値。

はい、もちろんです。

このことを考慮：

• 単体テストは、小さなコードを実行する小さなターゲットテストです。適切なコードカバレッジを実現するためにそれらの多くを書くので、すべて（または厄介なビットの大部分）がテストされます。
• 統合テストは、コードの大部分を実行するテストの大規模で幅広い部分です。適切なコードカバレッジを達成するためにそれらのいくつかを記述して、すべて（または厄介なビットの大部分）がテストされるようにします。

全体的な違いをご覧ください。

この問題はコードカバレッジの1つです。統合/受け入れテストを使用してすべてのコードの完全なテストを達成できれば、問題はありません。コードがテストされます。それが目標です。

すべてのユニットが実際に連携して動作することを確認するために、すべてのTDDベースのプロジェクトに何らかの統合テストが必要になるため、それらを混同する必要があると思いますそれらをすべてまとめると！）

問題は、テスト、障害のデバッグ、およびそれらの修正の容易さにあります。一部の人々は、単体テストがこれに非常に優れていると感じています。小さくてシンプルで、失敗が見やすいですが、欠点は、ユニットテストツールに合わせてコードを再編成し、それらの多くを書く必要があることです。統合テストは、多くのコードをカバーするために書くのがより難しく、おそらくロギングなどの手法を使用して障害をデバッグする必要があります（ただし、とにかくこれを行う必要があると思いますが、障害を単体テストすることはできませんオンサイト！）。

どちらにしても、テスト済みのコードが得られるので、どちらのメカニズムがより適しているかを判断するだけです。（少しミックスして、複雑なアルゴリズムの単体テストを行い、残りを統合テストします）。

それは恐ろしいアイデアだと思います。

受け入れテストと統合テストは、特定のターゲットをテストするためにコードのより広い部分に触れるため、それらは少なからず、より多くのリファクタリングを必要とします。さらに悪いことに、これらはコードの広範なセクションをカバーしているため、より広い範囲の検索対象があるため、根本原因の追跡に費やす時間が増加します。

いいえ、90％UIなどの奇妙なアプリや、単体テストでは扱いにくい他のアプリがない限り、通常は単体テストをもっと書く必要があります。あなたが直面している痛みは、単体テストではなく、テストを最初に開発することです。一般的に、ほとんどのライティングテストでは、時間の3分の1しか費やすべきではありません。結局のところ、彼らはあなたに奉仕するためにそこにいますが、その逆ではありません。

TDDの「メリット」は、テストが記述されると、テストを自動化できることです。逆に、開発時間のかなりの部分を消費する可能性があります。これが実際にプロセス全体の速度を低下させるかどうかは議論の余地があります。引数は、事前テストにより、開発サイクルの終了時に修正されるエラーの数が減ることです。

ユニットテストに動作を含めることができるため、ここでBDDが使用されます。そのため、定義上、プロセスは抽象的ではなく具体的​​になります。

明らかに、無限の時間が利用可能であれば、さまざまな種類のテストを可能な限り多く行うことになります。ただし、一般的に時間は限られているため、継続的なテストはある程度の費用効果があります。

これはすべて、最も価値のあるテストをプロセスの先頭に置くべきだという結論につながります。これ自体では、あるタイプのテストが別のタイプよりも自動的に優先されるわけではありません。それぞれのケースでメリットを考慮しなければなりません。

個人用のコマンドラインウィジェットを作成している場合、主に単体テストに関心があります。一方、Webサービスでは、かなりの量の統合/動作テストが必要になります。

ほとんどのタイプのテストは「レーシングライン」と呼ばれるもの、つまり今日のビジネスに必要なもののテストに集中しますが、ユニットテストは後の開発フェーズで表面化する可能性のある微妙なバグを取り除くのに優れています。これは容易に測定できない利点であるため、しばしば見落とされます。

単体テストの最後の利点は、高速であることです。ユニットテストとほぼ同じ速度で実行できることを知るために、十分な統合テストを作成しました。

これが重要なポイントであり、「最後の利点」だけではありません。プロジェクトがますます大きくなると、統合受け入れテストはますます遅くなります。そして、ここで、私はあなたがそれらの実行を停止しようとしているほど遅いことを意味します。

もちろん、単体テストも遅くなりつつありますが、それでも桁違いに高速です。たとえば、以前のプロジェクト（c ++、約600 kLOC、4000個のユニットテスト、200個の統合テスト）では、統合テストの実行に15分以上かかったのに約1分かかりました。変更するパーツの単体テストを構築して実行するには、平均で30秒もかかりません。あなたがそれをとても速くすることができるとき、あなたはいつもそれをしたいと思うでしょう。

明確にするために：統合テストと受け入れテストを追加しないとは言いませんが、TDD / BDDを間違った方法で行ったようです。

単体テストも設計に適しています。

はい、テスト容易性を念頭に置いて設計すると、設計が改善されます。

問題は、テストの作成/リファクタリングに関して、開発時間の半分以上がかかっていたことです。したがって、リファクタリングして多くのテストに書き込む必要があるため、最終的にはこれ以上機能を実装したくありませんでした。

まあ、要件が変わると、コードを変更する必要があります。単体テストを作成しなかった場合、作業を終了しなかったことを伝えます。しかし、これはユニットテストで100％をカバーする必要があるという意味ではありません-それは目標ではありません。いくつかのこと（GUIやファイルへのアクセスなど）は、ユニットテストすることさえ意図されていません。

この結果、コードの品質が向上し、テストの別のレイヤーができます。価値があると思います。

また、数千の受け入れテストもあり、すべてを実行するには1週間かかりました。