Hibernate の世界では、単体テストは成功したように見えても、キャッシュされたデータを扱っているために実際には現れないバグが存在することがよくあります。たとえば、保存をカスケードしていると考えて、親とその子を保存する場合があります。保存後に親を再クエリし、子コレクションのサイズをテストすると、問題ないように見えます。しかし実際には、Hibernate は子を保存しませんでしたが、親をキャッシュしたので、保存されていない子を見ています。これを回避する 1 つの方法は、保存とクエリの間にセッション キャッシュをクリアして、データがデータベースから直接取得されていることを確認することです。
これは ActiveRecord の問題ですか? モデルを保存して同じテストでクエリを実行すると、実際にはデータベースからではなく、クエリ キャッシュからデータを取得している可能性はありますか? これに対処しようとするサンプル テストは見たことがありません。
はい。テストの書き方によっては、Rails クエリ キャッシュが干渉することがあります。Rails は、キャッシュをクリアする必要がある場合 (オブジェクト間に明らかな関連付けがある場合) を追跡するのに十分なほどスマートな場合がありますが、期待どおりに動作しない例を次に示します。
user.posts.should == []
Post.create(:user_id => user.id)
user.posts.size.should_not == [] # Fails, since the original query was cached.
一般に、同じテストで同じクエリを 2 回実行する場合は、2 番目のクエリを実行する前に、データに対して .reload を呼び出す必要があります。そのようです：
user.posts.should == []
Post.create(:user_id => user.id)
user.posts.reload
user.posts.size.should_not == []
私の個人的な経験では、上記の方法を使用するよりも、別の方法でテストを作成することを検討することをお勧めします。たとえば、クエリ キャッシュの影響を受けない、上記をより適切に記述する方法を次に示します。
lambda { Post.create(:user_id => user.id) }.should_change(user.posts, :count).by(1)
ActiveRecord の問題としてこれに遭遇したことはありません。私の理解では、キャッシュは読み取り専用であるため、保存は常に実行されます。