フェイルファスト・テスト
GitLab 13.1で導入されました。
テストの実行に RSpec を使うアプリケーションのために、マージリクエストの変更に基づいてテストスイートのサブセットを実行する Verify/Failfast
テンプレートが導入されました。
このテンプレートはtest_file_finder
(tff
) gem を使用しており、入力ファイルとしてファイルのリストを受け取り、入力ファイルに関連すると思われる spec (テスト) ファイルのリストを返します。
tff
はRuby on Railsプロジェクト向けに設計されているため、Verify/FailFast
テンプレートはRubyファイルの変更が検出されたときに実行されるように設定されています。デフォルトでは、GitLab CI/CDパイプラインの.pre
ステージ で、他のすべてのステージの前に実行されます。
使用例
フェイルファストテストは、プロジェクトに新しい機能を追加したり、新しい自動テストを追加したりするときに便利です。
プロジェクトには何十万ものテストがあり、その完了には長い時間がかかります。新しいテストが通ると期待しても、それを検証するためにはすべてのテストが完了するまで待たなければなりません。これには、たとえ Parallels を使用していたとしても、 1 時間以上はかかるでしょう。
Fail Fast テストは、パイプラインからのフィードバックループを高速化します。新しいテストがパスし、新しい機能が他のテストを壊していないことをすぐに知ることができます。
前提条件
このテンプレートには
- テストにRSpecを使用するRailsで構築されたプロジェクト。
- CI/CDの設定:
- Rubyが利用可能なDockerイメージを使用します。
- マージリクエストパイプラインの使用
- プロジェクト設定でマージ結果のパイプラインを有効にします。
- Rubyが利用可能なDockerイメージ。テンプレートはデフォルトで
image: ruby:2.6
。
高速RSpec失敗の設定
出発点として、以下のプレーンなRSpec設定を使用します。すべてのプロジェクト gems をインストールし、マージリクエストパイプラインのみrspec
を実行します。
rspec-complete:
stage: test
rules:
- if: $CI_PIPELINE_SOURCE == "merge_request_event"
script:
- bundle install
- bundle exec rspec
スイート全体ではなく、最も関連性の高いspecを最初に実行するには、include
、CI/CD設定に以下を追加してテンプレートを作成します:
include:
- template: Verify/FailFast.gitlab-ci.yml
ジョブをカスタマイズするために、特定のオプションを設定してテンプレートを上書きすることができます。例えば、デフォルトのDockerイメージを上書きする場合:
include:
- template: Verify/FailFast.gitlab-ci.yml
rspec-rails-modified-path-specs:
image: custom-docker-image-with-ruby
テストロードの例
説明のために、Railsアプリの仕様スイートがモデルあたり100仕様、10モデルで構成されているとします。
Rubyファイルが変更されていない場合:
-
rspec-rails-modified-paths-specs
はテストを実行しません。 -
rspec-complete
は 1000 個のテストを実行します。
Ruby モデルが一つ変更された場合、例えばapp/models/example.rb
の場合、rspec-rails-modified-paths-specs
はexample.rb
の 100 テストを実行します:
- この 100 個のテストがすべて合格すると、
rspec-complete
の 1000 個のテストがすべて実行されます。 - これらの100のテストのどれかが失敗した場合、それらはすぐに失敗し、
rspec-complete
。
最後のケースは、1000 個のテスト・スイートをすべて実行しないので、リソースと時間を節約できます。