10

RailsアプリのSeleniumテストでどのデータを使用しますか？フィクスチャからロードしますか？既存の開発データベースを使用しますか？別の（フィクスチャではない）データベースを使用しますか？

ここで自分の選択肢を検討しています。SeleniumGridの修正バージョンで実行される大規模なSeleniumテストスイートを備えたRailsアプリがあります。現在、プロセスの一部は、テストスイートが実行される前に、一度に大量のフィクスチャのセットをロードすることです。それはたくさんのデータです。そのほとんどは、本番データベースからエクスポートされたレポート情報です。最初に設定したとき、データをOracleからyamlにエクスポートしました。

一部のレポートテーブルでスキーマが変更されたため、もちろんフィクスチャデータを再生成する必要があります。たくさんあるので、ファイルを手作業で編集する価値はありません。ただし、スキーマを少し変更するたびに再生成する必要があるのは非効率的です。言うまでもなく、覚えておくべきもう1つのステップです。もっと良い方法はありますか？

編集：私はもともと、通常のRailsテストのように、各テストの前にフィクスチャをロードし、各テストの後にそれらをアンロードすることを意図していました。ただし、このレポートデータにより、フィクスチャのロードには約15分かかります。200以上のテストがあり、スイートは12時間ごとに実行されます。時空キャプテンを曲げることができます！

編集2：私はまた、この大きな備品のセットを持っていることは悪臭であることに同意します。ただし、レポートには多くのデータが集約されており、セレンテストの価値の多くはレポートをテストすることであるため、どのように削減するかはわかりません。

小さなデータセットであっても、スキーマの変更との調整を維持するための別のセットです。（ユニット、機能、および[Rails]統合テスト用に個別の小さなセットがあります。）

これは私の元の質問に戻ります-手でそれを行う以外に、または毎回それらを再生成することを覚えている他のオプションはありますか？

4

3 に答える 3

5

可能であれば、最善の方法は、各 Selenium テストが独自のデータ状態を取得するシステムを用意することです (つまり、DB テーブルを削除して再作成し、ブートストラップ データを再挿入し、キャッシュをクリアします)。これは言うは易く行うは難しであり、通常、プロジェクトが最初から計画されている場合にのみ可能です。

次善の策は、各テスト スイート/実行に対して一貫した DB 状態を維持することです。一部のテストが以前に実行されたテストの成功に依存する可能性が高くなり、真の失敗と偽陰性の識別がより困難になるため、これはそれほど良いことではありません。

最悪の場合、IMO は、各テスト実行で日付が変更される静的 DB を使用することです。これはほとんど常に問題を引き起こし、通常は「プロジェクトの匂い」です。「正しい方法」(これも IMO) を実行するための鍵は、状態/スキーマの変更に注意を払い、自動化されたテスト/ビルド プロセスの一部としてそれをキャプチャすることです。

Rails はすでに Migrations でこれをうまく処理しているので、Migrations を利用してください! あなたの状況を知らなくても、私は通常、完全な DB のスナップに対して Selenium テストを実行する必要があるかどうか疑問に思います。ほとんどの DB は、自動化されたテストのために 1MB 未満にまで圧縮できる (または圧縮する必要がある) ため、自動化されたスキーマの移行とデータのリセットがはるかに効率的になります。

Selenium テスト用の大規模な DB の「有効な」理由は、DB 自体に、データがアプリケーション フローに影響を与える「ロジック データ」の大きなチャンクが含まれている場合のみです (データ駆動型 UI を考えてください)。

于 2009-03-13T21:03:17.697 に答える
3

私はあなたがここで絡み合っている2つの質問をしていると思うので、私がそれを分解する場合：

  • テストデータをDBにすばやく出し入れしたいのですが、フィクスチャがそれを実行していません。
  • あなたはスキーマの変更に悩まされており、「テストデータをいじる...それでも」をテーマにした8回の反復を必要としないことを確認したいと考えています:)

ここには、以下でハッシュ化したいくつかの選択肢があります。ここでOracleについて言及したので、ここではOracleテクノロジーを使用していますが、他のDBプラットフォーム（Postgresqlなど）についても同じことが言えます。

  1. PL / SQLスクリプトを呼び出してデータを生成するレーキテストは、厄介で恐ろしい邪悪な考えです。他に選択肢がない限り、それを行わないでください。いくつかのインフラストラクチャアーキテクチャテストのために数十億行をロードする必要がある1つのプロジェクトでそれを行いました。私はまだそれについて不機嫌です。
  2. DBをダンプ形式にします。迅速なバイナリダンプについては、exp/impおよびデータポンプユーティリティを確認してください。これにより、DBのセットアップと分解をすばやく行うことができます。確かに、私が取り組んだRailsプロジェクトでは、レーキタスクを使用して、1分以内に約30万件のレコードを持つデータベースをexp/impしました。また、論理ダンプユーティリティであるSQLローダーも確認してください。論理的に低速であり、SQLローダーがダンプを理解するのに役立つ制御スクリプトが必要です。ただし、論理ダンプの利点は、それらに対して変換スクリプトを実行して、データを最新の形式にマッサージできることです。残念ながら、フィクスチャと同じように、これらのツールはすべてスキーマの変更にかなり敏感です。
  3. MachinistやFactoryGirlなどのプラグインを使用して、データの生成をより適切にします。それでも、ActiveRecordを使用してDBをセットアップするというペナルティが発生しますが、これらの偽のオブジェクトジェネレーターは、移行の近くにとどまるのに役立ち、フィクスチャよりも保守の手間が大幅に軽減されます。
  4. アプローチ2と3を組み合わせます。ここで行われるのは、たとえばMachinstを使用してテストデータを作成することです。そのテストデータをダンプにエクスポートし、各テスト実行中にダンプをリロードします。スキーマが変更されたら、Machinistの構成を更新して再エクスポートします。

お役に立てば幸いです。

于 2009-03-15T03:38:02.693 に答える
1

私は現在、巨大な Selenium テスト スイート (実際には、Selenium Grid が作成されたもの) を含むプロジェクトに取り組んでおり、テストでは少量の参照データ (ただし、Rails YAML フィクスチャは使用していません) とオブジェクト ファクトリを使用しています。特定のテストに必要な 1 回限りのデータ用。

別の方法として、私が参加した多くの ThoughtWorks Rails プロジェクトでは、コミットを許可する前にテストを実行するなど、多数のプレコミット フックを組み込んだチェックイン スクリプトを作成しました。試してみることを検討できることの 1 つは、スキーマの変更をチェックし、必要に応じて参照データをリロードする同様のチェックイン スクリプトを作成 (またはカスタマイズ) することです。

たとえば、Githubの Paul Gross のrake commit tasksを参照してください。

于 2009-03-13T19:38:23.890 に答える