私は現在、多額のRailsテストスイートを見ています。詳細については何も言えませんが、スイート全体 (ユニット/機能/一部の統合) の実行時間は 5 分以上かかる場合があります。
私たちはフィクスチャに完全に依存しており、必要なほどモックやスタブを行っていません。
次の数回のスプリントでは、テスト スイートに完全に焦点を当て、カバレッジを改善し、より良いテストを作成し、最も重要なこととしてより効率的なテストを作成します。
したがって、テスト内でのモックとスタブの追加は別として、フィクスチャをおそらく Factory Girl に置き換えることを検討しています。私は多くの幸せな人々が同様の状況を経験しているのを見てきましたが、工場に引っ越すことのマイナス面についての良いリソースを見つけることができませんでした. さまざまなリソースのベンチマークを使用すると、ベンチマークが遅くなるのを見てきましたが、ファクトリが優れている理由と、ファクトリを使用したくない理由を明確に見つけることができません。
ファクトリを使用すべきではない理由または理由について誰かが教えてくれますか?
ありがとう！
オレグの答えは素晴らしいですが、両方を使用している人の視点を提供させてください。
備品は、しばらくの間、Railsコミュニティのウィッピングボーイでした。誰もが備品の欠点を理解していますが、実際に彼らの強みを擁護している人は誰もいません。私の経験では、ファクトリ自体はフィクスチャと同じくらい簡単に保守するのが難しくなる可能性があります（実際にはスキーマに依存しますが、私は逸脱します）。工場の真の強みは、器具に基づく痛みを選択的に置き換えることです。いくつかの詳細について話しましょう。
最初の問題はパフォーマンスです。データベースにアクセスせずにほとんどのアプリをテストできる場合は、大幅な速度向上が見られますが、ほとんどのアプリケーションでは、データベースに完全にアクセスせずにテストするのは賢明ではないと思います。ある時点で、スタック全体をテストしたいとします。モックやスタブを作成するたびに、微妙なバグが含まれている可能性のあるインターフェイスについて推測します。したがって、かなりの割合のテストでデータベースにアクセスする必要があると仮定すると、トランザクションフィクスチャ（トランザクションフィクスチャを使用していますか？）は、すべてのテストで環境全体をインスタンス化するよりもはるかに高速である可能性があります。
テストスイートのサイズを考えると、開発を次のレベルに拡大するために継続的インテグレーションに目を向ける必要があります。どれだけスピードを上げても、開発者が待つのはまだ長い時間です。たぶん、個人レベルで役立つように自動テストも見てください。しかし、最終的にCIを使用すると、開発者の敏捷性を犠牲にすることなく、テストの規律を維持できます。
フィクスチャが本当に輝く場所は、機能/統合テストです。私の見方では、フィクスチャは、テストするアプリの正常な基本状態を設定する必要があります。ほとんどの単体テストは実際にはこれを必要としません。工場を使用すると、非常に優れたユニットカバレッジを得ることができます。ただし、機能テストに関しては、特定のページが数十のモデルにヒットする可能性があります。各テストでそれらすべてを設定したくありません。より複雑なシナリオを構築するにつれて、フィクスチャが最初に実行するように設計されたものとまったく同じグローバルデータ状態の再作成にますます近づいています。
私が抱く物議を醸す信念の1つは、他のすべてが等しいということです。私は20の単体テストよりも1つの機能テストを好みます（Railsの用語を使用）。なんで？機能テストは、ユーザーに送信される最終結果が正しいことを証明するためです。単体テストは機能の微妙な違いを理解するのに最適ですが、結局のところ、サイト全体を壊すようなバグがインターフェースに沿って発生する可能性があります。機能テストは、実際にブラウザにページをロードせずに、デプロイを実行する自信を与えてくれます。すべてをスタブして両方のインターフェイスをテストし、同じカバレッジを取得できることはわかっていますが、CPUを少し犠牲にして、スタック全体を1つの簡単なテストでテストできる場合は、それを実行したいと思います。
では、フィクスチャのベストプラクティスは何ですか？
また、Jay Fieldsのブログをお勧めします。これは、実用的なテストに関する非常に優れたアドバイスです。Jayのブログで私が最も気に入っているのは、テストは非常にプロジェクト固有であり、あるプロジェクトで機能するものが別のプロジェクトで機能するとは限らないことを彼が常に認めていることです。彼は教義が不足していて、実用主義が長い。