unit-testing - 単体テストにモッキングフレームワークが必要なのはなぜですか?

Question

最近、.NET の世界では、さまざまなモッキングフレームワークがすべて誇大宣伝されています。私はまだ彼らの何が素晴らしいのかをよく理解していません。自分で必要なモッキングオブジェクトを作成するのはそれほど難しくないようです。特に Visual Studio の助けを借りて、モックしたいインターフェイスを実装するクラスをすばやく作成し (ほとんどすべてを自動生成してくれます)、テストに必要なメソッドの実装を作成できます。終わり！数行のコードを節約するためだけに、モッキングフレームワークを理解するという面倒な作業を行う必要はありません。それとも、モッキングフレームワークはコード行を節約するだけではないのでしょうか?

score 32 · Accepted Answer

ようやくモックオブジェクトのコツをつかむと、二重盲検テストまたは対照群が科学的試験に不可欠であるのと同じ理由で、モックオブジェクトが単体テストに不可欠であることに気付きました。それらは、実際にテストしているものを分離します。

他のインターフェースを介したかなりの相互作用を持つクラスをテストしている場合、すべてのインターフェースをモックする必要があるコード行を節約するだけでなく、「例外が発生した場合に例外をスローする」予期しないメソッドが呼び出された」または「これらのメソッドが順不同で呼び出された場合の例外」。モックフレームワークを使用すると、非常に洗練されたものにすることができます。学習曲線が大きいことはすぐに認めますが、速度に慣れると、肥大化することなく単体テストをより完全にするのに役立ちます。

score 12 · Accepted Answer

あなたの質問で、モックフレームワークの重要なポイントの 1 つを実際に特定しました。モックを自分でコーディングするという事実は、開発者が気にする必要はありません。モッキングフレームワークは、インターフェイスの実装をプログラム的に提供するだけでなく、(モックの設定に基づいて) 機能します。

たとえば、ICustomerDAO をテストしていて、あるメソッドをそれぞれ異なる結果で 14 回テストしたい場合はどうしますか? 14 の異なるクラスを手動で実装しますか? 誰もがそうしたいとは思わないでしょう。

モックを使用すると、クラスの一部が実際に機能するかどうかに関係なく、クラスの一部で何が起こるかを定義できます。たとえば、いつでも例外をスローしたり、ゼロの結果を返したり、それを正しく処理したりするなどです。 ...

これらは優れた単体テストツールです。

score 8 · Accepted Answer

役立つかもしれない以前
の質問: モックとは何ですか? また、いつ使用する必要がありますか?
モック主義者と古典的なTDD

モッキングフレームワークを使用すると、テストをより迅速に生成でき、テストで発生すると予想されることが実際に発生していることをより適切に検証できることがわかりました。私は過去にスタブまたは偽物を自分で実装しました。必要なテストに固有のスタブを生成する必要があることがわかりましたが、これには多くの時間がかかりました。モッキングフレームワークを使用すると、同じテストをはるかに高速に作成できます。良いものは、簡単な構文でフェイク、スタブ、またはモックの生成をサポートします。

コツをつかむにはしばらく時間がかかります。しばらくは避けていましたが、@ Chameleonが述べている理由から、モックフレームワークなしでは機能しようとしません。

score 4 · Accepted Answer

Roy Osheroveは Mock Frameworks についての投票を行い、コメントセクションでは、Mock Framework が必要かどうかについて (簡単ではありますが) 議論があります。

私は個人的にあなたが述べたとおりに手動で行っており、十分に機能していますが、これは一般的にモックフレームワークに関する密接な意見ではなく、主に習慣から外れています.

score 3 · Accepted Answer

確かに、モックフレームワークが必要だとは思いません。これは他のフレームワークと同様であり、最終的には時間と労力を節約できるように設計されています。スタックやキューなどの独自の共通データ構造をロールすることもできますが、一般的には、選択した言語のコンパイラ/IDE に同梱されているクラスライブラリに組み込まれているものを使用する方が簡単ではないでしょうか?

モックフレームワークを使用する説得力のある理由は他にもあると思いますが、その答えは TDD とユニットテストの専門家に任せたいと思います。

score 2 · Accepted Answer

モックフレームワークについて私を悩ませていることの1つは、「i/pが与えられたときに関数がo/pを実行する必要がある」ということです。

when（mock.someMethod（ "some arg"））。thenReturn（ "something"）;

ステートメントは、多くの単体テストクラスに分散しています。

例を挙げて詳しく説明します。パラメータとして従業員IDが渡されたときに従業員オブジェクトを返すDAOインターフェイス関数getEmp（int EmpID）があったとしましょう。この関数が10の異なる単体テストクラスによってモックされていたと仮定します。将来、この関数が新しいバージョンのEmployeeオブジェクトを返すように変更された場合、この変更を更新するには、10個の異なるクラスのそれぞれに移動する必要があります。

短所は次のとおりです...

a）この変更を更新できるように、この関数をモックするすべてのクラスを把握する方法がわかりません。

b）モックDAOオブジェクトを使用する既存のテストケースは、モックが変更されていないため、緑色のままであるため、DAOインターフェイスに発生した変更を幸いにも認識していません。理想的には、1つのモッククラスを自分でコーディングしてどこでも使用した場合、新しいバージョンのEmployeeオブジェクトを更新する場所は1つだけになります。また、この1つの場所で更新すると、モックを消費する既存のテストケースがすべて壊れて、新しいEmployeeオブジェクトの更新を行うために必要な場所が正確にわかります。

私の見解についての考え。

score 2 · Accepted Answer

同じ理由で、NUnit なしで単体テストを作成しようとすることはありません。モッキングフレームワークは、何百もの単体テストで状態と動作を検証するのに役立ちます。2 週間程度の労力を費やして速度を上げるだけの価値があり、テストが必要なものに集中するのに本当に役立ちます。

score 0 · Accepted Answer

モックフレームワークの良い点の1つは、モックされるオブジェクトに期待値を設定できることです。期待を込めて、テスト対象のコードを実行するためのあらゆる種類の条件を設定できます。

score 0 · Accepted Answer

分離フレームワークまたはモックフレームワークを使用すると、必要なコードを依存関係なしでテストできます。これにより、実行時間の短いテストが可能になり、迅速なデバッグが可能になり、コードの周りにテストのセーフティネットを簡単に構築できます。異なるフレームワークには異なる機能があり、前述のように、それはツールであり、ジョブに適したツールを選択する必要があります。

score 0 · Accepted Answer

モッキングフレームワークに rhino モックを使用しました。私と他の 5 人の開発者は、8 か月のプロジェクトである大規模なエンタープライズアプリケーションでそれを使用しました。プロジェクトでは tdd を使用しました。それは価値がありました？私は推測する。すべてのプロジェクトでモックを使用しなければならないほど、モックを使用することの大きなセールスポイントはありましたか? 私の意見では、いいえ。これは必要なものではなく、試してみたい場合に使用できる単なるツールです。一部のプロジェクトでは、独自のモッククラスをロールアウトすることができます。これは、一部のユーザーが好むと言うものです。その方が簡単です。他のプロジェクトは大規模で、モックフレームワークが必要になる場合があります。キーワード (私の意見では) は必要かもしれません...どのくらいのコードカバレッジが必要ですか? 私にとって、それはモックを使用する際のもう 1 つの考慮事項です。私が tdd/rhino モックで行ったプロジェクトでは、80% のコードカバレッジが必要だったので、モックはそれを達成するのに役立ちました。

unit-testing - 単体テストにモッキング フレームワークが必要なのはなぜですか?

10 に答える 10

Related

Reference

unit-testing - 単体テストにモッキングフレームワークが必要なのはなぜですか?