私のRSpecテストには、2,000を超える例を含むRailsアプリケーションがあります。言うまでもなく、これは大規模なアプリケーションであり、テストする必要があることがたくさんあります。この時点でこれらのテストを実行することは非常に非効率的であり、非常に時間がかかるため、新しいビルドをプッシュする前にテストを作成することはほとんどお勧めできません。spec.optsに--profileを追加して、実行時間が最も長いサンプルを見つけました。実行に平均10秒かかるサンプルが少なくとも10個あります。あなたのRSpecエキスパートの間でそれは正常ですか？一例として、10秒は完全に長すぎますか？2,000の例を使用すると、すべてを完全にテストするにはかなりの時間がかかることがわかりますが、現時点では4時間は少し馬鹿げています。
最長の実行例については、どのようなときに見ていますか？ボトルネックを特定してスピードアップを図るために、既存の仕様をトラブルシューティングするにはどうすればよいですか。この時点では、毎分本当に役に立ちます。
perftools.rbテストフレームワークと一緒に使用して、ほとんどの時間を使い果たしているものを理解します。上位10件の電話に出て、それらを排除/スキムしてみてください。その後、幸せになるまで繰り返します。
回答:
10秒は、単一のテストを実行するには非常に長い時間です。私の直感は、仕様ターゲットが単体テストと統合テストの両方を同時に実行していることです。これは、プロジェクトが陥る典型的なことであり、ある段階で、より多く、より速く生産したい場合は、この技術的負債を克服する必要があります。これを行うのに役立ついくつかの戦略があります...そして、私が過去に使用したいくつかをお勧めします。
1.ユニットを統合テストから分離する
私が最初に行うことは、ユニットを統合テストから分離することです。次のいずれかの方法でこれを行うことができます。
哲学は、あなたはあなたの定期的なビルドを速くしたいということです-そうでなければ、人々はそれらを頻繁に実行するのにあまりにも幸せではないでしょう。だから、その領域に戻ります。通常のテストをすばやく実行し、継続的インテグレーションサーバーを使用して、より完全なビルドを実行します。
統合テストは、外部の依存関係（データベース、WebService、キュー、および一部はFileSystemを主張するものなど）を伴うテストです。単体テストは、チェックしたい特定のコード項目をテストするだけです。高速で実行する必要があります（45秒で9000が可能です）。つまり、ほとんどがメモリで実行されます。
2.統合テストを単体テストに変換する
単体テストの大部分が統合テストスイートよりも小さい場合は、問題があります。これは、矛盾がより簡単に現れ始めることを意味します。したがって、ここから、統合テストに代わるユニットテストの作成を開始します。このプロセスを支援するためにできることは次のとおりです。
統合テストを置き換える適切な単体テストができたら、統合テストを削除します。重複したテストは、メンテナンスを悪化させるだけです。
3.備品を使用しないでください
備品は悪です。代わりにファクトリー（マニシストまたはfactorybot）を使用してください。これらのシステムでは、より適応性の高いデータのグラフを作成できます。さらに重要なのは、外部データソースからデータを読み込むのではなく、使用できるメモリ内オブジェクトを作成できることです。
4.統合テストになる単体テストを停止するためのチェックを追加する
これでより高速なテストを実施できたので、これを阻止するためのチェックを再度行う時間です。
データベース（UnitRecord）にアクセスしようとしたときにエラーをスローするアクティブパッチをサルパッチするライブラリがあります。
また、ペアリングとTDDを試すこともできます。これにより、チームはより高速なテストを強制的に作成できます。
5.他のライブラリを使用して問題を解決する
誰かがspork（rails3の下のテストスイートのロード時間を短縮する）、hydra / parallel_tests-ユニットテストを並列に（複数のコア間で）実行することについて言及しました。
これはおそらく最後に使用する必要があります。あなたの本当の問題は、ステップ1、2、3にあります。それを解決すれば、追加のインフラストラクチャをロールアウトするためのより良い立場になります。
テストスイートのパフォーマンス向上に関する優れたクックブックについては、Grease Your Suiteプレゼンテーションをご覧ください。
彼は、次のような手法を利用することにより、テストスイートの実行時間を45倍高速化することを文書化しています。
Sporkを使用できます。2.3.xをサポートしています。
https://github.com/sporkrb/spork
または./script/spec_server 2.xで動作する可能性があります
また、データベース構成を編集することもできます（データベースクエリなどを本質的に高速化します）。これにより、テストのパフォーマンスも向上します。
例あたり10秒は非常に長い時間のようです。1秒以上かかるスペックは見たことがなく、ほとんどがはるかに短いです。ネットワーク接続をテストしていますか？データベースは書き込みますか？ファイルシステムは書き込みますか？
モックとスタブは可能な限り使用してください- データベースにヒットするコードを書くよりもはるかに高速です。残念ながら、モックやスタブも書き込みに時間がかかります（正しく行うのが困難です）。テストの作成に費やした時間とテストの実行に費やした時間のバランスをとる必要があります。
テストスイートの並列化を可能にする可能性のあるCIシステムの調査に関するAndrew Grimmのコメントの2番目です。そのサイズの場合、それが唯一の実行可能な解決策かもしれません。
何人かの人々が上記のハイドラについて言及しました。過去に大成功を収めてきました。最近、ヒドラを起動して実行するプロセスを文書化しました：http : //logicalfriday.com/2011/05/18/faster-rails-tests-with-hydra/
この種の手法は、デフォルトで適切に構造化された高速なテストを作成する代わりに使用すべきではないという意見に同意します。
ActiveRecordモデルを使用している場合は、BCrypt暗号化のコストも考慮する必要があります。
詳細については、このブログ投稿をご覧ください。http：//blog.syncopelabs.co.uk/2012/12/speed-up-rspec-test.html
fast_require gemが役立つかもしれません。その上、あなたの唯一の方法は、（あなたがしたように）プロファイリングして最適化するか、またはsprkか、仕様を並行して実行する何かを使用することです。http://ruby-toolbox.com/categories/distributed_testing.html
いくつかの簡単なヒントに従って、まだ試していない場合は、最初にほとんどの時間を費やしている場所を調査できます。以下の記事をご覧ください。
https://blog.mavenhive.in/7-tips-to-speed-up-your-webdriver-tests-4f4d043ad581
これらのほとんどは、テストに使用されたツールに関係なく適用される一般的な手順だと思います。