Bullet Gem を RSpec で効果的に使用するにはどうすればよいですか? 現在、現在の単体テスト フレームワークで使用すると、本番アプリケーションで発生することとは関係のないテスト自体内の n+1 クエリが原因で、多くの通知またはテストの失敗が発生するように感じます。値または関連付け。そのため、n+1 個の障害を修正するためにコントローラーやモデルに何も設定する必要はありません。むしろ、テスト セットアップで特定のエラーをスローしないように何かを設定する必要があり、アプリケーションの実際のパフォーマンスの向上は見られません。
1706 次
1 に答える
9
最も効果的な方法はまったくありません。テストで n+1 クエリを減らすことには、いくつかの正当な利点があるかもしれません。最も明白なのは、全体的な実行時間を短縮することです。ただし、テストが多すぎるか、可能性よりも大幅な利益が得られない可能性は十分にあります。また、アプリケーションの全体的な価値に貢献するためではなく、テストをサポートするために追加のコードを記述することは、たいてい魅力的ではありません。
あなたの時間の代わりの使い方を提案させてください。快適なレベルの絶対的な最小値に対する単体テストのみ。私は個人的に、検証関連の問題とお金やその他の数学を含む複雑な方法に焦点を当てるのが好きです.あなたは異なる優先順位を持っているかもしれません. 線を引くことで、メンテナンス予算の大部分を占める、テスト スイートの最も役に立たない壊れやすい部分を書くための多くの時間を解放できます。
さて、余った時間をどうするか？心配する必要はありません。私たちはあなたにできることを見つけます... いくつかの受け入れテストを書くことから始めることができます。特に、たくさんの単体テストをドロップしたばかりのオブジェクトを使用する領域についてです。これで、n+1 警告は、ユーザーがページにアクセスしたときと同じ場所から実際に発生しています。これで、n+1 個のクエリをすべて削除できます。
ちょっと待って！それもしないでください。代わりに、タッチオプションを使用するために関係を設定する時間を大幅に短縮してください。次に、子オブジェクトが更新されると、親も更新されます。これが n+1 クエリと一体何の関係があるのだろうと疑問に思うかもしれません。クエリを追加しているようです...
そこで、ロシア人形のキャッシングの出番です。これを追加して適切にテストすると、解放された単体テストと n+1 の消去時間 (注意しないとさらにいくらか) が消費されます。良いことは、それがより「現実世界」であり、モデルやその他の重要でないまたは無関係な実装の変更に対する回復力がはるかに高く、すべてを熱心にロードすることによってすべての n + 1 クエリを排除することをはるかに超えて、アプリケーションのパフォーマンスが大幅に向上することです。前もって提供した可能性があります。この方法を最大限に活用するには、可能な限りネストされたキャッシュに移行し、すべてを可能な限り遅延してロードする必要があります。
n+1万歳！
于 2014-10-08T07:59:53.387 に答える