Martin Fowler のMocks Aren't Stubsを読みました (そして読み直しました) 。その中で、彼は TDD への 2 つの異なるアプローチを定義しています: "Classical" と "Mockist"です。彼は、「それで、私は古典主義者または模倣者であるべきですか?」という質問に答えようとしますが、「おもちゃ以外のもの」で模倣者の TDD を試したことがないことを認めています。そこで、ここで質問しようと思いました。良い答えは、Fowler の主張を繰り返したり (できればもっと明確に)、Fowler が最後に 2007 年 1 月にエッセイを更新して以来、彼が思いつかなかった議論や他の人が思いついた議論を追加するかもしれません.
Daryl Spitzer
質問する
8445 次
5 に答える
42
どちらかを選ぶ必要はないと思います。どちらにも長所と短所があり、どちらもツールボックスのツールです。"Mockist" tdd を使用すると、テストできる内容が少し柔軟になりますが、従来の TDD を使用すると、実際の実装ではなく入力/出力の出力を確認する傾向があるため、テストの脆弱性が少し緩和されます。模擬ユニットテストを行うとき、実装を変更すると、より多くのテストが中断するようです。
私は可能な限り従来の tdd を使用するようにしています (ただし、スタブをすばやくセットアップするためにモッキング フレームワークを使用することがよくあります)。一度にテストを開始しすぎたり、テストをセットアップするために必要なオブジェクトが多すぎたりすることがあります。そのような場合に、模擬テストが小規模なテストのセットアップに役立つことがよくあります。
これはすべて非常に抽象的なので、意味をなすことを願っています
于 2008-10-08T20:27:08.457 に答える
28
mockist または classic tdd に関する質問は、アプリケーションのどの部分をテストしているかに大きく関係しています。「標準」の階層化アーキテクチャ (たとえばDDDなど) を使用している場合、ドメイン層は通常、テスト対象のオブジェクトをセットアップして単体テストを行い、いくつかのメソッドを呼び出して結果や状態を確認する従来の tdd に適しています。
一方、より多くの調整作業を行うアプリケーション サービス、コントローラー、またはプレゼンテーション ロジックをテストしている場合は、適切なテストを得るためにモックまたはスタブが必要になることがよくあります。私の経験では、これらのクラスは、実際にモックまたはスタブしたい他のレイヤー (Web サービス、データレイヤーなど) を呼び出す傾向があることもわかっています。これらの単体テストにはさらに多くのセットアップ コードが必要になるため、必要な場合にのみモックを作成する必要があります。
私のアドバイスは、できる限りクラシックに進み、必要なときにモックすることです。
于 2008-10-20T21:10:32.767 に答える
17
http://www.growing-object-Oriented-software.com/にある私たちの本を見ることを検討してください。これには、拡張された実例が含まれています。私たちが書いたように、状態と相互作用の区別は主に誤解を招くものであり、オブジェクト指向デザインへのアプローチに関するものであることがわかりました。
于 2009-05-21T16:53:11.717 に答える
2
私はまだTDDに比較的慣れていませんが、違いを教えられたり紹介されたりした方法は、クラス間の統合をテストするという観点から考え、ライブデータに依存しないようにすることでした。たとえば、ほとんどスタンドアロンのクラスがある場合、プロジェクト用に構築した他のクラスに依存せず、入力用のライブデータ/開発環境（DBやAPIなど）に送信されません。システム）その後、NUnitやJUnitのようなもので古典的な単体テストのみを使用しますが、ビルドされたクラス間の相互作用をテストし始めると、他のカスタムクラスや外部の相互作用をモックするのに非常に便利になります。呼び出している他のクラスの潜在的なバグを追跡しようとせずに、現在のクラスのコードを選択してテストできます。
于 2008-10-20T15:17:12.387 に答える