0

proxy_options について知ったとき、それを使用してすべての名前付きスコープをテストし始めました。しかし、その後、条件ハッシュをモデルから直接コピーするだけで、結果の正確性を実際にテストしていないことに気付きました。

  po = {:conditions => "foo.created_at <= '#{Time.now.beginning_of_week}'"}
  assert_equal po, Foo.created_this_week

もう 1 つのアプローチは、肯定的な例と否定的な例を考え出し、それらが結果に含まれているかどうかを確認することです。

  this_week = Foo.make(:created_at => Time.now)
  last_week = Foo.make(:created_at => 1.week.ago)
  assert Foo.created_this_week.include?(this_week)
  assert !Foo.created_this_week.include?(last_week)

しかし、これは境界をチェックする良い仕事をしません。物事がより複雑になると、assert includes? の長いリスト全体が表示されます。予想される結果のセットを考え出し、それが一致することを確認するだけの方が良いようです:

  Foo.make(:created_at => 1.week.ago)
  results = [Foo.make(:created_at => Time.now)]
  assert_equal results, Foo.created_this_week

ただし、指定した順序とは異なる順序で結果が返されると、テストが失敗する可能性があります。モデルに <=> を実装して、両方の配列をソートできると思います。しかし、それは本当に必要ではないようです。これらの種類の検索方法をテストするより良い方法はありますか? または、少なくとも一般的に受け入れられている正しい方法ですか？

4

1 に答える 1

0

これを行うための「一般的に受け入れられている正しい方法」はないという結論に達したと思います。

私の個人的な解決策は、単純なnamed_scopesのテストをやめて、アサートインクルードを使用することだと思いますか? より複雑な検索機能をテストする方法。

于 2009-12-09T17:53:55.477 に答える