私にとっての重要な違いは、統合テストは現実に近いシナリオでコードにストレスを与えるため、機能が機能しているか壊れているかを明らかにすることです。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]その方法については単独で責任を負います。
また、Logが 100 の他の機能、100 の他のクラスの 100 の他のメソッドで使用されているとします。
はい、100 個の機能が失敗します。しかし、幸いなことに、100 のエンド ツー エンド テストも失敗し、問題が明らかになりました。そして、はい:彼らは真実を語っています.
これは非常に有益な情報です。製品が壊れていることはわかっています。また、非常に紛らわしい情報でもあります。どこに問題があるかについては何も教えてくれません。根本的な原因ではなく、症状を伝えます。
しかし、DoSomethingの単体テストは緑色Logです。壊れないように構築された偽の を使用しているためです。そして、はい:明らかに嘘をついています。壊れた機能が動作していることを伝えています。どのように役立ちますか？
(DoSomething()の単体テストが失敗した場合は、[Do your job with someInput]いくつかのバグがあることを確認してください。)
これが壊れたクラスを持つシステムであるとします:
1 つのバグがいくつかの機能を壊し、いくつかの統合テストが失敗します。
一方、同じバグは 1 つの単体テストだけを壊します。
ここで、2 つのシナリオを比較します。
同じバグが壊れる単体テストは 1 つだけです。
- 壊れたものを使用しているすべての機能
Logは赤です
- すべての単体テストは緑色で、単体テストのみ
Logが赤色です
実際、壊れた機能を使用するすべてのモジュールの単体テストは、モックを使用して依存関係を削除したため、緑色です。つまり、完全に架空の理想的な世界を走っているのです。そして、これがバグを特定して探す唯一の方法です。単体テストとは、モッキングを意味します。モックしていない場合は、単体テストではありません。
違い
統合テストは、何が機能していないかを示します。しかし、問題がどこにあるのかを推測するのには役に立ちません。
単体テストは、バグの正確な場所を示す唯一のテストです。この情報を引き出すには、他のすべての依存関係が正しく機能するはずの模擬環境でメソッドを実行する必要があります。
そのため、「または、2つのクラスにまたがる単なる単体テストですか」という文は、どういうわけかずれていると思います。単体テストが 2 つのクラスにまたがることはありません。
この返信は基本的に、私がここに書いたことの要約です:ユニットテストは嘘をつきます。