5

適切なテストを行うためにかなりの量のデータ (数千のレコード) を必要とするアプリケーションがあります。テスト可能で適切なデータの適切なセットを取得する唯一の方法は、実稼働 DB のサブセットを使用することです。これを通常の「test/fixtures」の場所にある YAML フィクスチャに変換しました。

これは機能しますが、条件Xを満たす特定の数のレコードであることに依存する、一見脆弱なテストとアサーションがたくさんあります...

def test_children_association
  p = Parent.find(1)
  assert_equal 18, p.children.count, "Parent.children isn't providing the right records"
end

これは私には良い考えではないように思えますが、データの大規模な階層を必要とするアプリケーションをテストするためのより良い/受け入れられた方法があるかどうかはわかりません.

4

5 に答える 5

8

テストのマジックナンバーはアンチパターンではありません。テストは非常に単純である必要があるため、テストする必要はありません。これは、いくつかのマジックナンバーがあることを意味します。これは、機能を少し変更するとテストが失敗することを意味します。これはいい。

フィクスチャにはいくつかの問題がありますが、フィクスチャを操作しやすくするために実行できる簡単なことがいくつかあります。

  1. フィクスチャにはベースラインデータのみが含まれます。これは、ほとんどのテストで必要であるが気にしない種類のデータです。これには事前に時間の投資が必要になりますが、プロジェクトの存続期間中、不十分な単体テストを作成するよりも、早い段階で苦痛を感じる方がよいでしょう。

  2. テストのコンテキストでテストするデータを追加します。これにより、テストの読みやすさが向上し、単体テストの開始時に「誰もフィクスチャを台無しにしないようにする」健全性チェックを書く必要がなくなります。

于 2008-10-23T12:03:08.003 に答える
0

私が最初に言うことは、その例で何をテストしているのかということです。それが通常のARhas_manyアソシエーションである場合、私はそれのテストをわざわざ書くことはありません。あなたがしているのは、ARが機能することをテストすることだけです。

より良い例は、非常に複雑なクエリがある場合、または子レコードのリストの取得に関連する他の処理があった場合です。それらを取り戻すとき、カウントをテストするのではなく、返されたリストを繰り返し処理して、子が使用している基準に一致することを確認できます。

于 2008-10-23T08:27:05.753 に答える
0

この状況で私が最も役立つと思ったのは、フィクスチャをまったく使用せず、データベースオブジェクトをオンザフライで構築することです

def test_foo
   project = Project.create valid_project.merge(....)
   *do assertions here*
end

私のtest_helpersには、たくさんのメソッドがあります:

def valid_project
   { :user_id => 23, :title => "My Project" }
end

def invalid_project
   valid_project.merge(:title => nil)
end

テスト オブジェクトの膨大なコレクションを構築しなければならないという苦痛から、より単純で用途の広いクラス構造を自然に設計するようになったことがわかりました。

于 2008-10-23T10:04:16.837 に答える
0

キャメロンの右: 何をテストしていますか?

テストするために何千ものレコードが必要なシステムは何ですか? テストはできるだけ小さくし、アプリケーションの動作をテストする必要があることを忘れないでください。これらのテストの大部分に何千ものレコードが必要になるわけはありません。

オブジェクトの関係が必要なちょっとした動作テストについては、モック オブジェクトを検討してください。テストに合格するために必要な動作の正確な最小量を指定するだけで、DB にはまったくヒットしません。これにより、テスト スイートのパフォーマンスが大幅に向上します。実行速度が速ければ速いほど、実行する頻度が高くなります。

于 2008-10-25T12:55:20.250 に答える
0

ここでは特殊な状況が発生する可能性がありますが、このアプリをテストするにはかなりの数のレコードが必要でした (150 程度にまで減らしました)。履歴データを分析しており、さまざまなレベルのhas_many. 私のメソッドの中には、いくつかのテーブルに対してカスタム SQL クエリを実行するものがありますが、これを変更して使用することになるかもしれませんがActiveRecord.find、最初にテストを実行する必要がありました。

とにかく、最終的にいくつかのruby​​ コードを使用してフィクスチャを作成しました。コードは my に含まれていtest_helperます。テスト DB をチェックして、データが古いかどうか (時間条件に基づいて) を確認し、手順に従ってレコードをワイプして再作成します。この場合、手続き的に作成することで、テストしているデータがどうあるべきかを知ることができますこれは、本番データのサブセットを使用して、最初に計算した数値が将来テストする必要があることを期待するよりも安全です。 .

また、ActiveRecord アソシエーションのテストを次のように簡単にする、他の多くの便利な機能とともに、Shouldaを使用するようになりました。

should_have_many :children
should_belong_to :parent
于 2008-10-25T17:06:41.750 に答える