モック (この場合は「ダブル」) をいつ使用するか、実際の依存関係 (この場合は「ファクトリ」) に対して統合するかについて考えるためのベスト プラクティスがあると思います。テスト駆動開発の目的を説明しているテストに関する非常に優れた本 (注意: Java の例を使用しています) があり、Rails アプリケーションでのテストに関するこの議論に非常に役立つと思います。テストの意図を次のように説明しています。
... テスト駆動開発における私たちの意図は、オブジェクト間の関係を引き出すためにモック オブジェクトを使用することです。
フリーマン、スティーブ。プライス、ナット (2009-10-12)。テストによって導かれるオブジェクト指向ソフトウェアの成長 (Kindle Locations 3878-3879)。ピアソン教育 (米国)。キンドル版。
リグレッションの発生を防ぐためだけでなく、インターフェイスや他のオブジェクトとの関係に関してコードがどのように構成されているかを考えるのに役立つように、テスト駆動開発を使用することを強調することを考えると、多くの場合、自然にモックを使用します。 . これがあなたの特定の質問にどのように当てはまるかを以下に説明します。
まず、モデル テストでモック オブジェクトを使用するか、実際の依存関係を使用するかという点で、クラス Foo とその Bar への依存関係をテストする場合、Bar をモックに置き換えたいと思うかもしれません。このようにして、呼び出されるメソッドをモックする必要があるため、Bar への結合のレベルを明確に確認できます。Bar のモックが複雑であることがわかった場合は、おそらく Foo と Bar をリファクタリングして、相互の結合を少なくする必要があることを示しています。
Factory.createどちらも、関連するクラスへの依存関係を明示的にしないようにするという同じ効果があるという意味でFactory.build_stubbed、Factory.create は 2 つのオプションの中で遅いため、どちらも同じくらい臭いと思います。
私のテストでは、コントローラーの外部依存関係をモックすることについてあまり心配しない傾向があります。これは完全なモックよりも実行が遅く、モデルへのコントローラーのカップリングを明示的にする利点がないことはわかっていますが、テストを書く方が速く、一般的に、コントローラーと、コントローラーが管理する永続レコードとの関係。「スキニー コントローラー」のパターンに従っている限り、とにかくここで心配するロジックが多すぎることはありません。ここで「テスト臭」のレベルを指定する必要がある場合は、他の工場に依存するモデル テストよりも少し臭いが少ないと言えます。
装飾するクラスのファクトリに依存するデコレータについては、あまり心配する必要はありません。これは、定義上、デコレーターがデコレートするクラスと同じインターフェースを維持する必要があるためです。装飾は、ほとんどの場合、何らかの形式の継承で実装されます。method_missing被装飾者に委任するか、被装飾者の明示的なサブクラス化によって。このため、デコレーターが装飾するもののインターフェースから大きく逸脱すると、Liskov Substitution などの優れたオブジェクト指向プログラミングの他のルールを破ることになります。適切な継承のルールを破って装飾が適切に実装されていない限り、装飾するクラスへの結合はすでに存在しているため、装飾対象のテストが永続化またはスタブ化されたものに依存していても、事態はさらに悪化しません。飾るモノの工場。デコレーターのテストで工場に夢中になることができますが、それは IMO には関係ありません。
ほとんどの場合モックを好む場合でも、実際の依存関係を使用するいくつかの統合テストが必要であることに注意することが重要だと思います。これらは、分離された単体テストがクラスによって提供される機能のより多くのカバレッジを提供する、特定の価値の高いケースをカバーしていることがわかります。
いずれにせよ、私は上記のルールをすべて破ることがありますが、これらはテストを書く際に使用するガイドラインの一部にすぎません。他の人がテストでファクトリ (build_stubbed と実際に永続化) とモック オブジェクト (ダブル) をどのように使用しているかを聞くのを楽しみにしています。