4

どのシナリオ、アプリケーション/システムの領域などは、「クラシック」状態ベースのテストとモック オブジェクトの使用に最も適していますか?

4

6 に答える 6

10

テストが設計を推進する TDD/BDD の観点から取り組みます。

まず第一に、これは最初にデザインに関するものであることを覚えておいてください. Martin Fowler がこのすばらしい記事で議論しているように、モックはスタブではありません.

モック主義者のアプローチに同意したい場合は、mockobjects サイトとその記事Mock Roles, Not Objectsを参照することから始めることを強くお勧めします。彼らは本も出しています。

真実は、モック ファースト スタイルの設計が自分に向いていない、またはアプリケーションを介して正しく実行したくない (たとえば、ドメイン/サービス レイヤーをテストするときではない) と信じている場合でも、それでもテストダブルスを使用したい。xUnit テスト パターンでは、さまざまな種類のテスト ダブルとその目的について説明しています。

個人的には、ドメイン クラスをモックすることはないので、エンティティ/値オブジェクトをモックすることはありません. しかし、私は最近、モック オブジェクト スタイルのアプローチを何度も試しています。これにより、私のデザインが少し変わり、作業スタイルが快適であることがわかりました。MVC アプリでこのスタイルで作業する場合、おそらく自動化された受け入れテストから開始し、次にドメイン以外のオブジェクト (リポジトリ/サービスなど) を模擬するコントローラー テストを作成し、次にテストに移ります。これらのリポジトリ/サービスは、依存関係を再びモックします。ドメインエンティティ/値オブジェクトなどの面倒な依存関係がないクラスに到達すると停止します。続けて、ドメイン クラスによって実装される特定のロール インターフェイスに対してテストすることもできます。これは、mockobjects 担当者が推奨する方法ですが、現在、そのアプローチにはあまり価値がありません。

ここでテスト用の設計が重要であることを追加する価値があることは明らかですが、IoC/モッキング/DIP の例の 90% はインターフェイスと実装のペア(ICustomerRepository/CustomerRepository) を示していますが、代わりにロール インターフェイスを探すことに多くの価値があることを覚えておいてください。

于 2008-09-12T08:10:54.150 に答える
3

モックオブジェクトを使用することは、状態ベースのテストを行っていないことを意味するわけではありません。

于 2008-09-10T18:39:09.773 に答える
3

依存関係にはモックを使用する必要があります。私はそれが二者択一だとは思わない。通常、依存関係のモックを作成し、期待値 (呼び出しか状態か) を設定してから、テスト対象のユニットを実行します。次に、その状態を確認し、後でモックに対する期待を確認します。

于 2008-09-10T18:29:10.450 に答える
1

サービスを利用するときは、自社もサードパーティも、当然のようにインターフェースまでデザインするので、そこでのやりとりに注目しがちです。これにより、最小限のインターフェイスを設計することが奨励されます。

単純な計算やルックアップなどと同じように、値オブジェクトに焦点を当てたあらゆるものの状態をチェックします。

次回、Model/View/Controller-or-Presenter に通常従うものを設計する場合は、Model と View のインターフェイスを使用して Presenter First アプローチ (Google it) を試すことを強くお勧めします。これにより、スタブ/モックを効果的に使用する方法がよくわかります。

于 2010-01-19T16:23:33.940 に答える
0

そのスタイルの問題..モキスト対クラシックTDDer。
個人的に..可能な限り実際のクラスをテストしに行きます。モックを可能な限りトーンダウンします。IO（ファイルシステム、DB接続、ネットワーク）、サードパーティコンポーネントなど、テストの実行が遅い/難しいものを分離するためだけに使用します。

于 2008-09-10T19:26:23.637 に答える
0

経験豊富な TDD 担当者として、これは他の開発者からよく聞かれる質問です。私にとって、モック主義者対古典主義者の議論に巻き込まれるのは間違いです。そのような議論は誤解を招くからです。状態ベースの単体テストと動作ベースの単体テストは、ツールボックスの 2 つの異なるツールであり、相互に排他的であるべき理由はありません。

状態ベースの単体テストは、オブジェクトの外部インターフェイスと通信した後にオブジェクトの内部プロパティをクエリする場合に適しています。1 人以上の共同作業者が他のオブジェクトへのコストがかかる可能性のある呼び出しを伴う場合は、必ずそれらの呼び出しをスタブ化し、単純に共同作業者を無視してください。

動作ベースの単体テストは、単体テストの「方法」を検討し、オブジェクト間の関係を発見することに集中したい場合に適しています。これは、状態ベースの単体テストの従来の「何を」という質問とは対照的です。コラボレーターが特定の方法や順序で使用されていることを主張したい場合は、モック (アサーションを提供するスタブ) を使用します。

標準的な単体テストのプラクティスに集中することをお勧めします。実行する本番コードはできるだけ少なくし、テストごとに1 つのアサーションを使用します。これにより、「このテストで実行して主張したいことは何ですか?」と考えるようになり、その質問に対する答えが、適切な単体テスト ツールを選択するのに役立ちます。

于 2008-09-11T22:38:05.400 に答える