私は Rails で Web サイトを作成しており、これまで継続的インテグレーションのために travis-ci を使用してきました。継続的な統合と展開のために wercker も試しています。wercker でのテスト ステップは 25 分以上実行されたため失敗し、何らかの理由でテストに異常に時間がかかる可能性があることに気付きました。
私が取り組んでいるウェブサイトはかなり大きいですが、大規模ではありません。rspec と capybara を使用してテストし、統合テストには webkit を使用します。各機能を確実にカバーできるように、かなり徹底的な統合テストを書いています。travis-ci では、プロセス全体の実行に 25 ～ 30 分かかります (バンドルのインストールを含む)。
これはこのフォーラムにとって漠然とした質問かもしれませんが、それにもかかわらず、いくつかの情報を得たいと思います。テスト スイートを 30 分以上実行することは容認できませんか? 一連の統合テストで、通常どのくらいのテスト スイートを経験しますか?
商用の Web サイトには、適切に設計されたものであっても統合テスト スイートがあるのが普通ですが、開発者のマシンで 1 つのプロセスで実行すると、実行に 1 時間以上かかります。したがって、テストを書きすぎている、またはテストの実行速度が異常に遅いと考える理由はありません。ただし、コミットが適切であったかどうかを知るのを待つには長すぎます。私の経験では、30 分は長すぎます。すべてのテストを実行するのにそれほど時間がかかる場合、ビルドをトリガーした人は、ビルドの実行中に何か他のことを開始したり、ビルドの実行中にさまよったりして、コンテキストを切り替える必要があるか、ビルドが壊れたときにそこにいなくなります。ビルドが長くなると、特定のビルドの平均コミット数も増加するため、ビルドが壊れたときに責任を割り当てることが難しくなります。
したがって、CI ビルドをできるだけ速く実行するようにしてください。大きなトピックですが、いくつかの出発点:
parallel_testsボックスでできるだけ速く実行する方法です(これだけでは十分ではありませんが、今のところは十分かもしれません)。コードの大部分またはすべてをカバーし、統合テストよりもはるかに高速 (数秒または最大で数分) で実行される単体テスト スイートを用意することも役立ちます。これにより、統合テストが実行される前にほとんどのエラーが検出されます。