11

単体テストでは手書きのスタブを使用しており、プロジェクトではEasyMockやMockitoなどのMockフレームワークの必要性を調査しています。

手書きのスタブからモックフレームワークに切り替える説得力のある理由は見つかりません。

手書きのモック/スタブを使用してユニットテストをすでに行っているのに、なぜモックフレームワークを選ぶのか、誰か答えてください。

ありがとう

4

5 に答える 5

16

簡単な答えは、それらは必要ないということです。

他の既存のフレームワークも必要ありませんが、モッキング フレームワークを使用すると、作業が楽になります。開発者として、モック フレームワークでできることを作成したり実行したりするよりも、目の前の問題により多くの時間を費やすことができます。

「手書きのスタブからモッキング フレームワークに切り替える説得力のある理由が見つかりません。」

私もまったく同じでした。わざわざモッキング フレームワークを学習する必要があるのはなぜですか? 手書きのスタブは問題ありません。

主に、しばらくするとテストがテスト スタブでわかりにくくなるという事実です。手書きのスタブを使用するときに参照しているものは、テスト拡張として知られています。コードを拡張して、モック フレームワークの機能を有効にします。つまり、コードをスタブに記述したり、何が起こったかに応じて値を返したりします。これには時間と労力がかかります。スペースは言うまでもありません。モッキング フレームワークは、これらすべてを数行で実行できます。

モッキング フレームワークの利点は次のとおりです。

  • 簡単です（主観的ですが、しばらくすると手書きの実装を書かなくなります）
  • 少ないコード (フレームワークを使用すると、完全なクラス宣言ではなく、数行でモックを作成できます)
  • DRYに従います（モック実装を繰り返すことはありません）

最大のメリットは、モック オブジェクトが必要な場合です。メソッドが呼び出されたかどうか、何回呼び出されたかなどを確認するためにコードを手書きする必要があるのは、それ自体が小さなタスクです。他の誰かがそうし、徹底的にテストされ、十分に文書化されたフレームワークを作成した場合、それを使用しないのは意味がありません。他のフレームワークと同様に、フレームワークがなくても問題なく作業できますが、適切なツールを使用すると作業がはるかに簡単になる場合があります。

于 2010-05-04T12:41:32.393 に答える
9

Martin Fowler のMocks Aren't Stubsの記事を読むことをお勧めします。基本的な違いは次のとおりです。

  • スタブの仕事は、既知の結果をすべての呼び出しに返すことです
  • モックはさらに、特定のパラメーターを使用して特定の順序で呼び出しが行われることを期待し、これらの期待が満たされない場合に例外をスローします。

スタブでテストできないエラー状態がいくつかあります。一方、モックを使用したテストは、多くの場合、安定性がはるかに低くなります。

スタブは妥当な労力で手動で作成できますが、モックははるかに多くの作業が必要になります。また、優れたモッキング フレームワークを使用すると、スタブの作成も高速かつ簡単になります。

于 2010-05-04T12:27:25.267 に答える
2

他のすべての開発者と同じように、既存のソリューションを使用する代わりにコードを書いていることに気付きます。これは「ここで発明されていない」症候群です。

あなたの質問は、それを行うフレームワークを使用するのではなく、2 回偽造/モックする必要があるクラスを作成することを好むことを示唆しています。モッキング フレームワークを使用すると、フェイク オブジェクトを変更するたびに、手作業で作成したモックを作成、リファクタリング、更新する必要がなくなります。

つまり、モッキング フレームワークを使用することは、ORM などの他のサード パーティ ライブラリとまったく同じです。

于 2010-05-04T12:25:11.267 に答える
2

私は同じ方法で始めました (手でモックを書く) が、今ではほぼ完全に EasyMock に切り替えています。

通常、EasyMock を使用すると、より高速で柔軟になります。

通常、初めてモックが必要になるときは、EasyMock を使用して数行のコードで作成できますが、必要なインターフェイスを手動で実装する必要があります (公平に言えば、これは IntelliJ などの IDE で生成できます)。必要な応答を生成するため、および/またはそれへの呼び出しの影響を感知できるようにするために必要なコードを追加します。

1 回限りのコストだと言う人もいるかもしれません。次回は、手書きのモックを喜んで再利用できます...そうではないことがよくあります。別のテストでは、動作が異なる同じクラスのモックが必要になる場合があります。たとえば、さまざまなメソッドが呼び出されたり、さまざまな結果が期待されたりします。特定のケースとは、あるテスト ケースではモックが例外をスローするが、別のテスト ケースではスローしないことが期待される場合です。動作を動的に制御するパラメータをいくつか追加できます。次に、次のテストでは、より多くの動作を制御するためのパラメーターがいくつかあります...したがって、ますます複雑なモック実装になり、これはますます多くの単体テストの依存関係になり、古いテストを誤って壊してしまう危険性もあります。

これとは対照的に、EasyMock を使用すると、テストごとに個別にモックを構成できます。したがって、動作は明示的に制御され、単体テスト コード自体の中で可視化され、副作用のリスクはありません。

言うまでもなく、EasyMock を使用すると、必要に応じて、必要なメソッドが必要な順序で呼び出されていることを確認できます (私は時々そうしています)。これを手動で (特に一般的な方法で) 実装するのは非常に面倒で、追加の利点はありません。

于 2010-05-04T12:13:59.917 に答える
1

宣言的な方法でモックを作成する方が簡単な場合もあり、フレームワークを使用すると、手動で作成するよりも簡単にある種の動作を記述することができます。もう 1 つの小さな利点は、モッキング フレームワークを使用することで、モッキングについて明示的になることです。

于 2010-05-04T12:18:23.167 に答える