👚 🔒 🧑🏾‍🤝‍🧑🏽 テストの並列化または1つのヘッドが適切であり、2つのヘッドが優れている 🌜 🦒 👇

ある時点で、テストカバレッジをコードの少なくとも80％に維持しようと一生懸命しようとすると、完全なテストスイートを実行すると、ブレークを吸ってHabrから新しい記事を読むのにかかるよりも時間がかかります。順番に、これは完全なセット（スイート）がますます少なく起動されるという事実につながります。ハドソンは壊れたビルドの報告を開始し、壊れたウィンドウ効果が機能し、壊れたビルドが標準になります。

各コミットの前に完全な実行を試みることができます。しかし、画面を横切って実行されるキュウリ機能の形で映画に費やされた時間は、ストリームを終了すると、開発者の効率を時々低下させます。

redmineの記録によると、チームの作業に約400時間を費やしたプロジェクトの1つで、並列化前のテストの状況は次のようになりました（数日前）。

151 scenarios (151 passed) 
      

        
        
        
      

     3997 steps (3997 passed) 
      

        
        
        
      

     17m49.257s

18分!!!

この間、開発者はコーヒーを入れたり、タバコを吸ったり、トイレに行ったり、お尻にかなりの同僚をつまんだりして、画面上の「マトリックス」の最後の3分間を見ることができます。各コミットの前にフルランを実行するように彼に要求する場合、彼は「マトリックス」を見て~~、司祭をつまんで~~コーヒーを飲むようにするだけです。

しかし、実行中のプロセッサ負荷の分析では、どれだけ多くのコアがあっても、作業に関与していることが示されています。 sayingにもあるように、1日を失ってから5分で飛ぶ方が良いでしょう。 Googleで調べたところ、 parallel_tests gemが見つかりました。 Selectelにあるレンタルされたクラウドマシンのクラスターでテストを安全に並列化できるアーラングループについては、このようなwith 望はありません。

parallel_tests gemは、対応するもの（ hydra 、 testjour ）と比較して、キュウリ+カピバラ+セレンWebドライバーのお気に入りの統合テストを並列化することができるという事実によって区別されます。 capybara firefox gem経由。この場合、Firefoxのいくつかのコピーが実際に起動され、その上で負荷がほぼ均等に分散されます。同時に、htopは、マシン上にいくつあるかに関わらず、すべてのコアの全負荷を示します。また、重要な役割を果たしているため、このgemを使用するようにアプリケーションを調整することは非常に簡単です。

まず、典型的なケースではコアごとに1つ、複数のテストベースの存在を確認する必要があります。 gem自体は起動時に環境変数TEST_ENV_NUMBERを設定するため、testセクションのdatabase.ymlで設定できます

test: 
      

        
        
        
      

     database: xxx_test<%= ENV['TEST_ENV_NUMBER'] %>

当然、ベースは、実行または通過する前に手動で作成する必要があります

rake parallel:create

第二に、追加の移行または再構築中にデータベーススキームの同期を確保する必要があります。

rake parallel:prepare

第三に、別の方法で実行を実行します。

rake parallel:features

これは、キュウリ機能を実行するためのものです。 rspecおよび通常のレールテストを実行できます。

はい、もちろん、gemはGemfileに登録して置く必要があります

bundle install

その結果、これらは8コアXelektelovsky Xeoncegでの最後のハドソンアセンブリの結果です。

Results: 
      

        
        
        
      

     17 scenarios (17 passed) 
      

        
        
        
      

     347 steps (347 passed) 
      

        
        
        
      

     31 scenarios (31 passed) 
      

        
        
        
      

     780 steps (780 passed) 
      

        
        
        
      

     8 scenarios (8 passed) 
      

        
        
        
      

     149 steps (149 passed) 
      

        
        
        
      

     26 scenarios (26 passed) 
      

        
        
        
      

     1363 steps (1363 passed) 
      

        
        
        
      

     26 scenarios (26 passed) 
      

        
        
        
      

     463 steps (463 passed) 
      

        
        
        
      

     17 scenarios (17 passed) 
      

        
        
        
      

     331 steps (331 passed) 
      

        
        
        
      

     6 scenarios (6 passed) 
      

        
        
        
      

     88 steps (88 passed) 
      

        
        
        
      

     19 scenarios (19 passed) 
      

        
        
        
      

     410 steps (410 passed) 
      

        
        
        
      

     
      

        
        
        
      

     Took 338.989782947 seconds 
      

        
        
        
      

     Finished: SUCCESS

はい、並列化の使用に加えて、テストコードでリファクタリングが行われたため、手順とシナリオの数が削減されました。ただし、151対150-それほど多くはありません。しかし、やがて-ほぼ18対5分30秒です。これは、リポジトリからの新規プル、データベース移行、Firefoxの起動に約60〜70秒の一定のコストを考慮しています。

結果は明らかであり、その結果、わずか1日でハドソンのビルドが安定しました。最後の5回のコミットはすべてのテストに成功しました。

UPD：step_definitionsがパラレルモードで検出されない場合、解決策はAlderによって検出されます次に、次のようなテストを実行する必要があります。

parallel:features[2,'','--require features']

テストの並列化または1つのヘッドが適切であり、2つのヘッドが優れている

More articles: