9

test 以外の rails_env で rspec 仕様を実行するべきではないと言われました。

本番環境または開発環境で仕様を実行する際の潜在的な問題は何ですか? 私は両方で仕様を実行します。アセット パイプラインを使用するものをテストしていない限り、通常は dev で仕様を実行します。そのために本番環境に切り替え、アセットの事前コンパイルに 15 分を費やします。現在の方法よりもテスト環境を使用する利点はありますか?

答えを探しましたが、dev や prod を使用してはいけない理由を説明するものは何もありませんでした。

4

3 に答える 3

8

環境でテスト スイート ( rspecなど) を実行testすることは、セキュリティ上の懸念、特にデータベースの整合性のためにリソースを分離することを目的としています。テストによって、データベース内のデータが破損したり、完全に削除されたりすることがよくあります。

同じことがすべてのリソースに当てはまります。環境を使用するtestことで、リソースを切り離してモックできるため、テストで何かが破損するのを防ぐことができます。

個別の環境を使用する理由は多数ありますが、基本的にはリソースの分離であり、test環境のコンテキストでは、運用リソースと実行中のシステムの安全性を確保しながらアプリケーションの検証を可能にするためです。

于 2012-09-17T15:01:13.110 に答える
3

特にこの投稿を読んでいる可能性のある nubes について明確にしましょう: RAILS_ENV=production(ローカルで)は、「環境内で」テストを実行することと同じではありません。productionあなた（OP）はそれを知っていますが、本番環境でテストを実行する危険性により、この警告が保証されます。

環境内でのみ実行する理由はいくつかありますがtest、一般的には DB の処理に関連しています。

  • Rspec は、DB 内のデータのカスタム「バージョン」を構築し、それを操作して、一部の変更をディスクに永続化します。
  • 多くのテストは、テスト分離の終わりに向かって既存のデータを一掃し、物事をべき等にします。これにより、使用しているデータがテストで構築される可能性があります。

他の理由は、すでに推測したとおりです。

  1. prod 環境には、テストに使用される gem を含めないでください。どうして？：
    • gem をテストすると、ライブ アプリで不必要にロードして実行する必要があるコードがさらに追加されます。
    • テスト関連の gem は、本番アプリにセキュリティ ホールを導入する可能性があります。
  2. 特定のアセットは、「コンパイル」後に正しくテストされない場合があります。
  3. アセットやその他の deploy-pip-line プリコンパイルは、テスト プロセスのサービスで、別の方法で処理したり、オフにしたりできます。
  4. 特定の API およびサービスは、メールやレポートなどの従量制サービスへの API 呼び出しなど、テスト/ステージングでサンドボックス化またはスタブ化される場合があります。

可能性は (アプリに対して) あまりにもカスタマイズされているため、ベスト プラクティスを提案することはできません... しかし、言うまでもなく、次の場合に構成が必要になる可能性のある多くの「テスト モード」設定があります。rails_ENV=test

于 2012-09-17T14:43:41.960 に答える
0

優先順位を明確にする必要があります。なぜスペックを実行するのですか？

  1. 確かに、環境 xyz がコードを実行するか、
  2. 確かに、コードが正常に動作することを確認してください

NewAlexandriasの回答に示されている理由から、ほとんどのpplは2.の仕様を実行します。これは実際にはテスト環境で行う必要があります。

1. 導入後に確認したいのですが、動作スペックはちょっと大げさな気がします。もっと簡単な方法があるはずです。

展開するとき、2 について確信が持てません。 ... それは時期尚早の展開であり、何かをすべきではありません。

于 2012-09-17T14:55:20.093 に答える