単体テストと統合テストのいわゆる教科書の定義を知っています。私が気になるのは、単体テストを作成するときです。できるだけ多くのクラスのセットをカバーするように記述します。
たとえば、Wordクラスがある場合、クラスの単体テストをいくつか記述しWordます。次に、Sentenceクラスの記述を開始します。クラスとやり取りする必要Wordがある場合は、少なくとも両方が相互作用する場所で、両方Sentenceをテストするようにユニットテストを記述することがよくありWordます。
これらのテストは、これらの2つのクラスの統合をテストするので、本質的に統合テストになりますか、それとも2つのクラスにまたがる単なる単体テストですか？
一般に、この不確実なラインのため、統合テストを実際に作成することはめったにありません...または、完成品を使用して、すべての部分が実際の統合テストで適切に機能するかどうかを確認します。個々の機能の？
統合テストを誤解していますか、それとも統合テストと単体テストの違いはほんのわずかですか？
回答:
私にとっての主な違いは、統合テストは機能が機能しているか、機能していないかを明らかにするということです。これは、現実に近いシナリオでコードにストレスをかけるためです。1つ以上のソフトウェアメソッドまたは機能を呼び出し、期待どおりに動作するかどうかをテストします。
反対に、単一のメソッドをテストする単体テストは、すべての依存関係を明示的に模倣しているため、ソフトウェアの残りの部分が正しく機能しているという（しばしば間違った）仮定に依存しています。
したがって、いくつかの機能を実装するメソッドの単体テストが緑色の場合、それはその機能が機能していることを意味しません。
次のような方法があるとします。
public SomeResults DoSomething(someInput) {
var someResult = [Do your job with someInput];
Log.TrackTheFactYouDidYourJob();
return someResults;
}
DoSomething顧客にとって非常に重要です。それは機能であり、重要な唯一のものです。そのため、通常はそれをアサートするCucumber仕様を記述します。つまり、機能が動作しているかどうかを確認して通信したいとします。
Feature: To be able to do something
In order to do something
As someone
I want the system to do this thing
Scenario: A sample one
Given this situation
When I do something
Then what I get is what I was expecting for
間違いなく、テストに合格した場合は、機能する機能を提供していると断言できます。これは、ビジネスバリューと呼べるものです。
単体テストを作成するDoSomething場合は、残りのクラスとメソッドが機能している（つまり、メソッドが使用しているすべての依存関係が正しく機能している）と偽って（モックを使用して）、メソッドが機能していることをアサートする必要があります。
実際には、次のようにします。
public SomeResults DoSomething(someInput) {
var someResult = [Do your job with someInput];
FakeAlwaysWorkingLog.TrackTheFactYouDidYourJob(); // Using a mock Log
return someResults;
}
これを行うには、依存性注入、ファクトリメソッド、モックフレームワーク、またはテスト対象のクラスを拡張します。
にバグがあるとしLog.DoSomething()ます。幸い、Gherkin仕様で検出され、エンドツーエンドのテストは失敗します。
機能が機能していないのは、機能してLogいないためで[Do your job with someInput]はなく、機能していないためです。そして、ちなみに、[Do your job with someInput]その方法の唯一の責任です。
また、Log100の他の機能、100の他のクラスの100の他のメソッドで使用されているとします。
はい、100個の機能が失敗します。しかし、幸いにも、100のエンドツーエンドテストが失敗し、問題が明らかになっています。そして、はい：彼らは真実を語っています。
これは非常に役立つ情報です。製品が壊れていることはわかっています。また、非常にわかりにくい情報です。問題の場所については何もわかりません。根本的な原因ではなく、症状を伝えます。
それでも、DoSomethingユニットテストは環境にLog優しいものです。これは、決して壊れないように構築された偽物を使用しているためです。そして、はい：それは明らかに嘘をついています。壊れた機能が動作していることを伝えています。それはどのように役立ちますか？
（DoSomething()の単体テストが失敗した場合は、必ず確認してください：[Do your job with someInput]いくつかのバグがあります。）
これが壊れたクラスを持つシステムであるとします：
単一のバグはいくつかの機能を壊し、いくつかの統合テストは失敗します。
一方、同じバグは1つの単体テストを壊すだけです。
次に、2つのシナリオを比較します。
同じバグが1つの単体テストを壊すだけです。
Logいるすべての機能は赤ですLogが赤です実際には、モックを使用して依存関係を削除したため、壊れた機能を使用するすべてのモジュールの単体テストは緑色です。言い換えれば、彼らは理想的な、完全に架空の世界で実行されます。そして、これがバグを分離してそれらを探す唯一の方法です。単体テストはモックを意味します。あざけっていなければ、単体テストではありません。
統合テストは、何が機能していないかを示します。しかし、問題がどこにあるのかを推測するのにそれらは役に立ちません。
単体テストは、バグの正確な場所を示す唯一のテストです。この情報を描画するには、他のすべての依存関係が正しく機能するはずのモック環境でメソッドを実行する必要があります。
そのため、「2つのクラスにまたがる単体テストなのか」という文章は、どうにかして置き換えられていると思います。単体テストは2つのクラスにまたがってはなりません。
この返信は、基本的には私がここに書いたものの要約です。ユニットテストは嘘です。それが私がそれらを愛している理由です。
単体テストを作成するときは、依存関係をモックすることによって、テストしているコードのスコープを、現在作成しているクラスに制限します。Sentenceクラスを作成していて、SentenceがWordに依存している場合は、モックWordを使用します。Wordをモックすることで、Wordのインターフェースにのみ焦点を当て、Wordのインターフェースとやり取りするSentenceクラスのさまざまな動作をテストできます。この方法では、文の動作と実装のみをテストし、同時にWordの実装をテストしていません。
ユニットテストを記述して、Wordのインターフェイスに基づいてSentenceがWordと相互作用するときに正しく動作することを確認したら、統合テストを記述して、相互作用に関する私の仮定が正しいことを確認します。このために、実際のオブジェクトを提供し、文とWordの両方を使用することになる機能を実行するテストを記述します。
私の10ビット：D
ユニットテストは個々のコンポーネントのテストであり、最大限に実行する必要があるといつも言われていました。現在、ほとんどのコンポーネントは小さなパーツで構成されているため、これには多くのレベルがある傾向があります。私にとって、ユニットはシステムの機能的な部分です。したがって、何か価値のあるものを提供する必要があります（つまり、文字列解析のメソッドではなく、おそらくHtmlSanitizerです）。
統合テストは次のステップです。1つまたは複数のコンポーネントを取得し、コンポーネントが正常に機能することを確認します。コンポーネントが個別にどのように機能するかについては、複雑な問題よりも上ですが、htmlをHtmlEditControlに入力すると、どういうわけか魔法のようにそれが有効かどうかを知っています。
しかし、その実際の可動ライン..私はむしろ、いまいましいコードが完全に機能するようにすることにもっと焦点を当てたいです^ _ ^
単体テストはモックを使用します
あなたが話しているのは、システムの統合全体を実際にテストする統合テストです。ただし、ユニットテストを行う場合は、実際には各ユニットを個別にテストする必要があります。他のすべてはあざける必要があります。したがって、Sentenceクラスの場合、それがWordクラスを使用している場合は、Wordクラスをモックする必要があります。この方法では、Sentenceクラスの機能のみをテストします。
統合テストについて考え始めると、論理層ではなく、物理層の間のクロスの話をしていると思います。
たとえば、テストがコンテンツの生成に関係している場合、それはユニットテストです。テストがディスクへの書き込みのみに関係している場合、それはユニットテストですが、I / Oとファイルのコンテンツの両方をテストすると、次に、統合テストを行います。サービス内の関数の出力をテストする場合、それは単体テストですが、サービスを呼び出して関数の結果が同じであるかどうかを確認したら、それは統合テストです。
技術的には、とにかく1クラスだけを単体テストすることはできません。クラスが他のいくつかのクラスで構成されている場合はどうなりますか？それは自動的に統合テストになりますか？そうは思いません。
ユニットテストモジュールXのは、モジュールXの問題（およびチェック）テスト期待していることです
多くのモジュールの統合テストは、モジュール間の連携から発生する問題を想定しているため、単体テストだけではこれらの問題を見つけるのは困難です。
テストの性質を次の用語で考えてください。
統合テストは、その依存関係の一部をまだスタブ/フェイク/モックする場合があることに注意してください。これにより、単体テストとシステムテスト（すべてのシステムをテストする最も包括的な統合テスト）の間に十分な中間点が提供されます。
したがって、実用的なアプローチは次のとおりです。統合テストを柔軟に信頼できる範囲で行い、リスクが高すぎたり不便であったりする場合は、単体テストを使用してください。この考え方は、単体テストと統合テストの独断的な区別よりも役立つ場合があります。
私の意見では、「なぜそれが重要なのか」という答えです。
ユニットテストはあなたがするものであり、統合テストはあなたがしないものだからです？またはその逆？もちろんそうではありません。両方を実行する必要があります。
ユニットテストは高速、分離、反復可能、自己検証、タイムリーである必要があり、統合テストはそうではないためですか？もちろん、すべてのテストはこれらでなければなりません。
単体テストではモックを使用しますが、統合テストではモックを使用しないためですか？もちろん違います。これは、有用な統合テストがある場合、一部にモックを追加することが許可されていない場合、テストの名前を「ユニットテスト」に変更するか、別のプログラマに引き渡して作業する必要があることを意味します。
単体テストは1つのユニットをテストし、統合テストは複数のユニットをテストするためですか？もちろん違います。それは実際にどの程度重要ですか？「ユニット」という用語は完全にコンテキストに依存しているため、テストの範囲に関する理論的な議論は実際には失敗します。クラスレベルでは、ユニットはメソッドである場合があります。アセンブリレベルでは、ユニットはクラスであり、サービスレベルでは、ユニットはコンポーネントである場合があります。そしてクラスでも他のクラスを使用しているので、ユニットはどれですか？
それは重要ではありません。
テストは重要であり、最初は重要です。定義に関するヘアを分割することは、時間の無駄であり、新規参入者をテストに混乱させるだけです。
私は同じことをしています-それらをすべて単体テストと呼びますが、ある時点で、多くの場合それをカバーする「単体テスト」があり、「.. IntegrationTest」に名前を変更します。名前を変更するだけで、それ以外は何も変更しません。
「アトミックテスト」（1つの小さなクラスまたはメソッドをテストする）からユニットテスト（クラスレベル）と統合テスト、そして機能テスト（通常、上から下にさらに多くのものをカバーする）への続きがあると思います-完全にカットオフされていないようです。
テストがデータをセットアップし、おそらくデータベース/ファイルなどをロードする場合、おそらくそれは統合テストに近いものです（統合テストではモックが少なく、実際のクラスが多く使用されますが、それはいくつかのモックアウトができないという意味ではありませんシステムの）。
単体テストは、必要に応じて、作業単位またはコードのブロックに対してテストします。通常、1人の開発者が実行します。
統合テストとは、開発者がコードをソース管理リポジトリにコミットしたときに、できれば統合サーバーで実行されるテストを指します。統合テストは、Cruise Controlなどのユーティリティによって実行される場合があります。
したがって、ユニットテストを実行して、構築した作業ユニットが機能していることを検証し、次に統合テストで、リポジトリに追加したものが他のものを壊していないことを検証します。
私はユニットテストをそれらのテストと呼び、ホワイトボックスはクラスをテストします。クラスが必要とする依存関係はすべて、偽の依存関係（モック）に置き換えられます。
統合テストは、複数のクラスとそれらの相互作用が同時にテストされるテストです。これらの場合の一部の依存関係のみが偽造/偽造されています。
依存関係の1つが実際のもの（つまり、偽造されていないもの）でない限り（たとえば、IFormsAuthentication）、コントローラーの統合テストを呼び出さないでください。
2つのタイプのテストを分離すると、さまざまなレベルでシステムをテストするのに役立ちます。また、統合テストは長寿命になる傾向があり、単体テストは迅速であることが想定されています。実行速度の違いは、それらが異なる方法で実行されることを意味します。私たちの開発プロセスでは、チェックイン時に単体テストが実行され（これは非常に高速です）、統合テストは1日に1回/ 2回実行されます。私はできる限り頻繁に統合テストを実行してみますが、通常はデータベースにアクセスする/ファイルに書き込む/ rpcを作成するなどが遅くなります。
これにより、別の重要なポイントが発生します。単体テストでは、IO（ディスク、ネットワーク、dbなど）のヒットを回避する必要があります。そうでなければ、彼らはたくさん減速します。これらのIO依存関係を設計するには少し労力が必要です-「単体テストは高速でなければならない」というルールに忠実であったことを認めることはできませんが、そうだとすれば、はるかに大規模なシステムでの利点がすぐに明らかになります。
上記の例は非常にうまく機能するので、繰り返す必要はありません。したがって、理解を助けるために例を使用することに焦点を当てます。
統合テストでは、すべてが連携しているかどうかを確認します。時計で一緒に働いている一連の歯車を想像してみてください。統合テストは次のようになります：時計は正しい時間を伝えていますか？それでも3日間で正しい時刻がわかりますか？
全体が機能しているかどうかがわかるだけです。失敗した場合：どこで失敗しているか正確にはわかりません。
これらは本当に特定のタイプのテストです。特定のものが機能しているか失敗しているかがわかります。このタイプのテストの鍵は、他のすべてが正常に機能していると想定しながら、特定の1つのテストのみをテストすることです。それがポイントです。
例：例 を使用してこの点について詳しく説明しましょう。
車の統合テストが失敗したとします。エチューカまでは車で行きません。問題はどこだ？
ここで、エンジンが特別な燃料噴射システムを使用していて、このエンジンの単体テストも失敗したと仮定します。つまり、統合テストとエンジン単体テストの両方が失敗しました。それでは問題はどこにありますか？（答えを得るために自分に10秒を与えてください。）
エンジンまたは燃料噴射システムに問題がありますか？
ここで問題がわかりますか？あなたは正確に何が失敗しているのか分かりません。異なる外部依存関係を使用している場合、それらの10のすべてが問題を引き起こした可能性があり、どこから始めればよいかわかりません。そのため、単体テストではスタブを使用して、他のすべてが正常に機能していると想定しています。
これらの2つのクラスの統合をテストしているため、これらのテストは本質的に統合テストになっていますか？それとも、2つのクラスにまたがる単体テストですか？
はい、そうです。2つのクラスにまたがる単体テストが統合テストになりました。
モック実装-MockWordクラスを使用してSentenceクラスをテストすることで、これを回避できます。これは、システムのこれらの部分が、さまざまな開発者が実装できるほど大きい場合に重要です。その場合、Wordは単体テストされ、SentenceはMockWordを使用して単体テストされ、その後、SentenceはWordとの統合テストが行われます。
実際の違いの例は次のとおりです。1）1,000,000要素の配列は簡単にユニットテストされ、正常に動作します。2）BubbleSortは、10要素のモックアレイで簡単にユニットテストされ、正常に動作します。
これらのパーツが1人で開発された場合、開発者がすでに実際の配列を使用していて、モック実装を必要としないという理由だけで、BubbleSoftのユニットテスト中に問題が発生する可能性が高くなります。
TDDの純粋主義者であれば、量産コードを記述する前にテストを記述します。もちろん、テストはコンパイルされないので、最初にテストをコンパイルさせてから、テストにパスさせます。
単体テストではこれを行うことができますが、統合テストや受け入れテストではできません。統合テストを試した場合、完了するまで何もコンパイルされません。
