Minitestで始めるRails 6のシステムテスト入門：設定から実行まで徹底解説

本記事では、Rails 6のシステムテストについて詳しく見ていきます。システムテストは、ユーザーがアプリケーションとやり取りする流れを自動的に検証するためのもので、UIに含まれるJavaScriptの動作もテスト対象になります。MinitestはRailsの標準テストフレームワークであり、システムテストとの相性は抜群です。Railsがほとんどの設定を引き受けてくれるため、最初のテストを動かすまでに必要なステップはごくわずかです。

システムテストはRails 5.1で導入されました。筆者が実際に使い始めた際、RSpecに関する情報は豊富にあるものの、Minitest向けの最新情報を集めるのが難しいと感じました。そこで本記事では、Minitestでシステムテストを扱うために収集した最新のノウハウをまとめてご紹介します。

システムテストとは何か

Railsの用語におけるシステムテストとは、「アプリケーションをひとつのシステム全体としてテストすること」を指します。具体的には、テスト内で実際にブラウザを操作することで実現されます。個別のコンポーネントを単体で検証するのではなく、ユーザーがアプリを操作するときに体験する「ワークフロー」全体を、JavaScriptの挙動も含めてエンドツーエンドでテストできるのが特徴です。

実践的には、ユーザーがボタンをクリックしたときにデータベースへレコードが作成されるかどうかを直接チェックするのではなく、その新しいレコードが画面上に表示されるかどうかを検証する、という形になります。この種のユーザーインタラクションテストは、フィーチャーテストやアクセプタンステストとも呼ばれます。インテグレーションテストがアプリ内部の各パーツの連携動作を（UIを介さずに）検証するのに対し、システムテストはあくまでユーザーの視点に立ったテストである点が異なります。

初期設定：驚くほどシンプル

システムテストの設定は非常にシンプルで、むしろ「本当にこれだけでいいのか？」と戸惑うほどです。

ブラウザ操作にはCapybaraというGemが使われます。Capybaraを通じて、テストコードからページへのアクセス、フォームへの入力、リンクやボタンのクリックなどを行えます。Capybaraを使った経験がある方なら、データベースクリーン戦略との連携やブラウザ設定など、調整すべき項目が多いことをご存じでしょう。ところがRailsのシステムテスト環境は、こうした設定をすべて最初から面倒見てくれるため、開発者はテストコードそのものの記述に集中できます。

公式ドキュメントによると、デフォルトではActionDispatch::SystemTestCaseがSeleniumドライバで駆動され、Chromeブラウザ、画面サイズ1400x1400で起動します。CapybaraのデフォルトではなくSeleniumが採用されているのは、JavaScriptを扱えるドライバだからです。

すべての設定はapplication_system_test_case.rbに集約されており、各テストファイルでこのファイルをrequireするだけで済みます。

# application_system_test_case.rb（デフォルト）

require "test_helper"

class ApplicationSystemTestCase < ActionDispatch::SystemTestCase
  driven_by :selenium, using: :chrome, screen_size: [1400, 1400]
end

Rails 6で新規アプリを生成した場合は、これだけで準備完了です。ネット上にあふれる「Seleniumドライバの手動セットアップ手順」やRSpecフィーチャーテスト向けの設定ガイドは、すべて読み飛ばして問題ありません。

既存アプリの場合でも、scaffoldを生成すればapplication_system_test_case.rbとシステムテストに必要なファイル一式が自動生成されます。

ちなみに、システムテスト導入時にChromeが採用されたのは、当時のFirefoxがSeleniumと相性が悪かったためです。この問題は後続のFirefoxバージョンで解消されているため、筆者は以下のようにFirefoxへ変更しています。

# application_system_test_case.rb（ドライバをFirefoxに変更）

require "test_helper"

class ApplicationSystemTestCase < ActionDispatch::SystemTestCase
  driven_by :selenium, using: :firefox, screen_size: [1400, 1400]
end

補足：以前はドライバ切り替え後に$ rails db:test:prepareを実行してクリーンな状態を担保していましたが、現在のテストランナーは:prepareタスクを自動実行してくれるため、この手順も不要になっています。

Rails 6での変更点

システムテスト導入時（5.1）に使われていたchromedriver-helper Gemは非推奨となり、新しいRails 6アプリではwebdrivers Gemに置き換えられました。Rails 5アプリをお使いの場合は、まだであればwebdriversへの移行をおすすめします。webdriversがあれば、selenium-webdriver Gemすら個別に不要になります。ちなみにRails 6では、両方のGemが同梱されています。

もう必要なくなったもの

かつてCapybaraのセットアップは苦痛そのものでした。ゼロから環境を整えるには、適切なデータベースクリーン戦略の選定、capybara-webkit Gemの依存関係の解決、その他予期しない要件への対応など、テストを書き始める前の下準備が山積みでした。今やRailsが必要なものをすべて提供してくれるため、混乱の原因はむしろ、ガイドやドキュメントに残る「時代遅れの情報」の方です。以下は、現在では無視してよい項目です。

• minitest-rails-capybaraなどのGemは不要。色付き出力、フェイルファスト、特定テストのみの実行といったMinitestの拡張機能は、Rails 5.0で導入されたテストランナーに組み込み済みです。
• database_cleaner Gemも不要。Railsがトランザクショナルテストとして自動的に後片付けを行います。
• RailsはCapybaraのデフォルトではなくSeleniumを採用しているため、capybara-webkitは不要で、JavaScript要素のテストのための追加設定も一切不要です。
• Capybaraのsave_and_open_screenshotを使う必要もありません。Rails純正のtake_screenshotメソッドが/tmpへスクリーンショットを保存し、テスト出力にアクセス用リンクを表示してくれます。

通常ブラウザとヘッドレスブラウザの使い分け

システムテストがブラウザ上で実行され、リンクがクリックされ、フォームが自動入力されていく様子を見るのは爽快ですが、残念ながら動作は遅めです。テスト実行を高速化したい場合は「ヘッドレスブラウザ」を活用しましょう。ヘッドレスブラウザとは、通常のブラウザと同等にアプリへアクセスできるものの、GUIを持たないブラウザのことです。動作は同じですが、実際のブラウザウィンドウが開かないため、テストの進行を目視できません。

ヘッドレスモードにはheadless_chromeとheadless_firefoxが用意されており、設定変更は1行だけです。

# application_system_test_case.rb（ヘッドレスドライバに変更）

require "test_helper"

class ApplicationSystemTestCase < ActionDispatch::SystemTestCase
  driven_by :selenium, using: :headless_firefox
end

注意：Railsドキュメントや過去の記事では、ドライバの選択肢としてPoltergeistが言及されていることがあります。PoltergeistはCapybara向けのヘッドレスPhantomJSドライバとして人気でしたが、PhantomJS自体がすでに開発終了しているため、新規採用は避けるべきです。ここで触れるのは、Railsドキュメントに今もその記述が残っているためです。

さらなるカスタマイズも可能ですが、導入としては以上で十分です。

テストの実行方法

$ rails testはシステムテスト以外の全テストを実行します。システムテストは明示的に$ rails test:systemで実行する必要があります。（豆知識：$ railsコマンドは常にbin/rails経由で実行されるため、$ bin/railsと打つ必要はもうありません。）

• すべてのシステムテストを実行：
  $ rails test:system
• 特定ファイルのテストを実行（例：users_test.rb）：
  $ rails test/system/users_test
• 特定の1テストのみ実行：
  $ rails test test/system/users_test.rb:21
• 全テストをシステムテストから先に実行：
  $ rails test:system test

注意：test:systemにはオプションフラグが効きません。-f（フェイルファスト）や-v（詳細出力）を使いたい場合は、$ rails test test/system -v -fのように指定してください。

何をテストし、何をテストしないか

システムテストはユニットテストの補完であり、代替ではありません。ハッピーパスに加えて、エラーメッセージ表示やリダイレクトが発生するケースを1つ程度カバーすれば十分です。ブラウザ上のあらゆるエッジケースを網羅する用途には向いていません。主要な機能の動線を押さえることに徹しましょう。

テスト対象の選定では、ユーザーの実際の利用シナリオを反映するエンティティを選ぶのがおすすめです。命名規則には、GitLab式のROLE_ACTION_test.rb（役割_アクション形式）が適しています。例：user_shares_card_test.rb のような形です。

実践的なヒントとコツ

• Deviseとの連携：認証にDeviseを使っている場合、統合ヘルパーでテストユーザーのログイン・ログアウトが簡単に行えます。テストクラスにinclude Devise::Test::IntegrationHelpersを追加するか、test_helper.rbに追記して全テストで利用可能にしましょう。ユーザーを作成してsign_in(@user)を呼ぶだけです。setupメソッド内に書けば、teardownでのログアウト処理も不要です。Railsがsetup内容を自動的にクリーンアップしてくれます。
• フォーム操作は「見える要素」で指定：Railsが自動生成するid（モデル名＋フィールド名）やclick_on :commitのような指定は便利ですが、システムテストはユーザーが画面で実際に目にするものを検証するものなので、表示テキストベースで指定するのが筋です。実運用では、i18nロケールファイルに参照キーを定義し、変わりやすいリテラル文字列の代わりにキーを使うのが堅実です（fill_in :user_email）。なお、CapybaraでI18nのテキストを照合するには完全な構文が必要です：assert_selector "h1", text: I18n.t("activerecord.models.things")
• パスヘルパーは標準搭載：URLヘルパーはデフォルトで利用可能です。一方、assert_emailsメソッドなどを使うには、include ActionMailer::TestHelperのようにテストクラスへ明示的なincludeが必要なライブラリもあります。
• 画面サイズ別のテスト：カスタムクラスを作成すれば、異なる画面サイズ（レスポンシブ確認など）でテストを実行できます。詳細は公式ガイドを参照してください。
• スクリーンショットの二次利用：スクリーンショット機能は、ドキュメントや販促素材の作成にも転用できます。スクリーンキャスト化して再生速度を落とせば、数分でプロダクト動画が完成します！
• ジェネレータの活用：Railsにはシステムテスト専用のジェネレータが用意されています。
• Rails版Minitestの仕様に注意：RailsのMinitestは素のMinitestとは微妙に異なり、Rails固有のメソッドやアサーションが追加されています。Minitest公式ドキュメントより先に、Railsドキュメントを確認する習慣をつけましょう。

筆者自身、システムテストをとても楽しんで使っています。その最大の理由は、最初からほぼ設定不要で動き出す手軽さにあります。

まとめ

本記事では、Railsが標準で提供するシステムテスト環境の設定内容と、必要最小限のカスタマイズ方法を解説しました。Minitestはシステムテストの記述に最適な相棒です。紹介したヒントとコツを参考に、ぜひ最初のシステムテストを立ち上げてみてください。ブラウザ上でテストが魔法のように動き回る様子は、一度見ると病みつきになりますよ。