railsguides.jp

目次

1. Railsアプリでテストを作成しなければならない理由
2. テストを導入する
   • Railsを即座にテスト用に設定する
   • test環境
   • RailsとMinitestの出会い
   • 最初の「失敗するテスト」
   • エラーの表示内容
   • 利用可能なアサーション
   • Rails固有のアサーション
   • テストケースに関する補足事項
   • Railsのテストランナー
3. テストデータベース
   • テストデータベースのスキーマを管理する
   • フィクスチャのしくみ
4. モデルテスト
5. システムテスト
   • デフォルト設定の変更
   • スクリーンショットヘルパー
   • システムテストを実装する
6. 結合テスト
   • 結合テストで使用できるヘルパー
   • 結合テストを実装する
7. コントローラの機能テスト
   • 機能テストに含める項目
   • 機能テストで利用できるHTTPリクエストの種類
   • XHR（AJAX）リクエストをテストする
   • 「黙示的な」3つのハッシュ
   • 利用可能なインスタンス変数
   • HTTPとヘッダーとCGI変数を設定する
   • flash通知をテストする
   • テストをまとめて行う
   • テストヘルパー
8. ルーティングをテストする
9. ビューをテストする
10. ヘルパーをテストする
11. メイラーをテストする
    • メイラーのテストについて
    • 単体テスト
    • 機能テスト
12. ジョブをテストする
    • 基本のテストケース
    • カスタムアサーションと他のコンポーネント内のジョブのテスト
13. その他のテスティング関連リソース
    • 時間に依存するコードをテストする

1 Railsアプリでテストを作成しなければならない理由

Railsを使用すれば、テストをきわめて簡単に作成できます。テストの作成は、モデルやコントローラを作成する時点でテストコードのスケルトンを作成することから始まります。

Railsのテストが作成されていれば、後はそれを実行するだけで、特に大規模なリファクタリングを行なう際にコードが期待どおりに動作していることを即座に確認できます。

Railsのテストはブラウザのリクエストをシミュレートできるので、ブラウザを手動で操作せずにアプリのレスポンスをテストできます。

2 テストを導入する

テスティングのサポートは最初期からRailsに組み込まれています。決して、最近テスティングが流行っていてクールだから導入してみた、というようなその場の思い付きで導入されたものではありません。

2.1 Railsを即座にテスト用に設定する

rails new application_nameでRailsアプリを作成すると、その場でtestディレクトリが作成されます。このディレクトリの内容は次のようになっています。

$ ls -F test
controllers/           helpers/               mailers/               system/                test_helper.rb
fixtures/              integration/           models/                application_system_test_case.rb

helpersディレクトリにはビューヘルパーのテスト、mailersディレクトリにはメイラーのテスト、modelsディレクトリにはモデル用のテストをそれぞれ保存します。controllersディレクトリはコントローラ/ルーティング/ビューをまとめたテストの置き場所です。integrationディレクトリはコントローラ同士のやりとりのテストを置く場所です。

システムテスト（system）ディレクトリにはシステムテストを保存します。システムテストは、ユーザーエクスペリエンスに沿ったアプリのテストを行うためのもので、JavaScriptのテストにも有用です。 システムテストはCapybaraから継承した機能で、アプリのブラウザテストを実行します。

フィクスチャはテストデータを編成する方法の1つであり、fixturesフォルダに置かれます。

ジョブに関連するテストが最初に作成されると、jobsディレクトリも作成されます。

test_helper.rbにはテスティングのデフォルト設定を記入します。

システムテストのデフォルトの設定はapplication_system_test_case.rbに保存されます。

2.2 test環境

デフォルトでは、すべてのRailsアプリにはdevelopment、test、productionの3つの環境があります。

それぞれの環境の設定はいずれも同様の方法で変更できます。テストの場合は、config/environments/test.rbにあるオプションを変更することでtest環境を変更できます。

2.3 RailsとMinitestの出会い

ガイドのRails をはじめようでrails generate modelコマンドを実行したのを覚えていますか。最初のモデルを作成すると、testディレクトリにはテストのスタブ（stub）が生成されます。

$ bin/rails generate model article title:string body:text
...
create  app/models/article.rb
create  test/models/article_test.rb
create  test/fixtures/articles.yml
...

test/models/article_test.rbに含まれるデフォルトのテストスタブの内容は以下のような感じになります。

require 'test_helper'

class ArticleTest < ActiveSupport::TestCase
  # test "the truth" do
  #   assert true
  # end
end

Railsにおけるテスティングコードと用語に親しんでいただくために、このファイルに含まれている内容を順にご紹介します。

require 'test_helper'

このファイルをrequireすると、テストで使うデフォルト設定としてtest_helper.rbが読み込まれます。今後書くすべてのテストにもこれを記述しますので、このファイルに追加したメソッドはテスト全体で使えるようになります。

class ArticleTest < ActiveSupport::TestCase

ArticleTestクラスはActiveSupport::TestCaseを継承することによって、テストケース をひとつ定義しています。これにより、ActiveSupport::TestCaseのすべてのメソッドをArticleTestで利用できます。これらのメソッドのいくつかについては後述します。

ActiveSupport::TestCaseのスーパークラスはMinitest::Testです。このMinitest::Testを継承したクラスで定義される、test_で始まるすべてのメソッドは単に「テスト」と呼ばれます。このtest_は小文字でなければなりません。従って、test_passwordおよびtest_valid_passwordと定義されたメソッド名は正式なテスト名となり、テストケースの実行時に自動的に実行されます。

Railsは、ブロックとテスト名をそれぞれ1つずつ持つtestメソッドを1つ追加します。この時生成されるのは通常のMinitest::Unitテストであり、メソッド名の先頭にtest_が付きます。これにより、メソッドの命名に気を遣わずに済み、次のような感じで書けます。

test "the truth" do
  assert true
end

上のコードは、以下のように書いた場合と同等に振る舞います。

def test_the_truth
  assert true
end

通常のメソッド定義を使ってもよいのですが、testマクロを適用することで、引用符で囲まれた読みやすいテスト名がテストメソッドの定義に変換されます。

次は最初のアサーションを見てみましょう。

assert true

アサーション（assertion）とは、オブジェクトまたは式を評価して、期待された結果が得られるかどうかをチェックするコードです。アサーションでは以下のようなチェックを行なうことができます。

• ある値が別の値と等しいかどうか
• このオブジェクトはnilかどうか
• コードのこの行で例外が発生するかどうか
• ユーザーのパスワードが5文字より多いかどうか

1つのテストにはアサーションが1つ以上含まれることがあります。すべてのアサーションに成功してはじめてテストがパスします。

2.4 最初の「失敗するテスト」

今度はテストが失敗した場合の結果を見てみましょう。そのためには、article_test.rbテストケースに、確実に失敗するテストを以下のように追加してみます。

test "should not save article without title" do
  article = Article.new
  assert_not article.save
end

それでは、新しく追加したテストを実行してみましょう（6はテストが定義されている行番号です）。

$ bin/rails test test/models/article_test.rb:6
Run options: --seed 44656

# Running:

F

Failure:
ArticleTest#test_should_not_save_article_without_title [/path/to/blog/test/models/article_test.rb:6]:
Expected true to be nil or false


bin/rails test test/models/article_test.rb:6



Finished in 0.023918s, 41.8090 runs/s, 41.8090 assertions/s.

1 runs, 1 assertions, 1 failures, 0 errors, 0 skips

出力に含まれている単独の文字Fは失敗を表します。Failureの後にこの失敗に対応するトレースが、失敗したテスト名とともに表示されています。次の数行はスタックトレースで、アサーションの実際の値と期待されていた値がその後に表示されています。デフォルトのアサーションメッセージには、エラー箇所を特定するのに十分な情報が含まれています。すべてのアサーションは失敗時のメッセージをさらに読みやすくするために、以下のようにメッセージをオプションパラメータとして渡すことができます。

test "should not save article without title" do
  article = Article.new
  assert_not article.save, "Saved the article without a title"
end

テストを実行すると、以下のようにさらに読みやすいメッセージが表示されます。

Failure:
ArticleTest#test_should_not_save_article_without_title [/path/to/blog/test/models/article_test.rb:6]:
Saved the article without a title

今度は title フィールドに対してモデルのレベルでバリデーションを行い、テストがパスするようにしてみましょう。

class Article < ApplicationRecord
  validates :title, presence: true
end

このテストはパスするはずです。もう一度テストを実行してみましょう。

$ bin/rails test test/models/article_test.rb:6
Run options: --seed 31252

# Running:

 .

Finished in 0.027476s, 36.3952 runs/s, 36.3952 assertions/s.

1 runs, 1 assertions, 0 failures, 0 errors, 0 skips

お気付きになった方もいるかと思いますが、私たちは欲しい機能が未実装であるために失敗するテストをあえて最初に作成していることにご注目ください。続いてその機能を実装し、それからもう一度実行してテストがパスすることを確認しました。ソフトウェア開発の世界ではこのようなアプローチをテスト駆動開発 ( Test-Driven Development (TDD) : TDD) と呼んでいます。

2.5 エラーの表示内容

エラーがどのように表示されるかを確認するために、以下のようなエラーを含んだテストを作ってみましょう。

test "should report error" do
  # some_undefined_variableはテストケースのどこにも定義されていない
  some_undefined_variable
  assert true
end

これで、このテストを実行するとさらに多くのメッセージがコンソールに表示されるようになりました。

$ bin/rails test test/models/article_test.rb
Run options: --seed 1808

# Running:

.E

Error:
ArticleTest#test_should_report_error:
NameError: undefined local variable or method 'some_undefined_variable' for #<ArticleTest:0x007fee3aa71798>
    test/models/article_test.rb:11:in 'block in <class:ArticleTest>'


bin/rails test test/models/article_test.rb:9


Finished in 0.040609s, 49.2500 runs/s, 24.6250 assertions/s.

2 runs, 1 assertions, 0 failures, 1 errors, 0 skips

今度は'E'が出力されます。これはエラーが発生したテストが1つあることを示しています。

テストが失敗すると、それに応じたバックトレースが出力されます。Railsはデフォルトでバックトレースをフィルタし、アプリに関連するバックトレースのみを出力します。これによって、フレームワークから発生する不要な情報を排除して作成中のコードに集中できます。完全なバックトレースを参照しなければならなくなった場合は、-b（または--backtrace）引数を設定するだけで動作を変更できます。

$ bin/rails test -b test/models/article_test.rb

このテストをパスさせるには、assert_raisesを用いて以下のようにテストを変更します。

test "should report error" do
  # some_undefined_variableはテストケースのどこにも定義されていない
  assert_raises(NameError) do
    some_undefined_variable
  end
end

これでテストはパスするはずです。

2.6 利用可能なアサーション

ここまでにいくつかのアサーションをご紹介しましたが、これらはごく一部に過ぎません。アサーションこそは、テストの中心を担う重要な存在です。システムが計画通りに動作していることを実際に確認しているのはアサーションです。

アサーションは非常に多くの種類が使用できるようになっています。 以下で紹介するのは、Minitestで使用できるアサーションからの抜粋です。MinitestはRailsにデフォルトで組み込まれているテスティングライブラリです。[msg]パラメータは1つのオプション文字列メッセージであり、テストが失敗したときのメッセージをわかりやすくするにはここで指定します。これは必須ではありません。

これらはMinitestがサポートするアサーションの一部に過ぎません。最新の完全なアサーションのリストについてはMinitest APIドキュメント、特にMinitest::Assertionsを参照してください。

テスティングフレームワークはモジュール化されているので、アサーションを自作して利用することもできます。実際、Railsはまさにそれを行っているのです。Railsには開発を楽にしてくれる特殊なアサーションがいくつも追加されています。

2.7 Rails固有のアサーション

Railsはminitestフレームワークに以下のような独自のカスタムアサーションを追加しています。

これらのアサーションのいくつかについては次の章でご説明します。

2.8 テストケースに関する補足事項

Minitest::Assertionsに定義されているassert_equalなどの基本的なアサーションは、あらゆるテストケース内で用いられているクラスで利用できます。実際には、以下から継承したクラスもRailsで利用できます。

• ActiveSupport::TestCase
• ActionMailer::TestCase
• ActionView::TestCase
• ActiveJob::TestCase
• ActionDispatch::IntegrationTest
• ActionDispatch::SystemTestCase
• Rails::Generators::TestCase

各クラスにはMinitest::Assertionsが含まれているので、どのテストでも基本的なアサーションを利用できます。

2.9 Railsのテストランナー

bin/rails testコマンドを使ってすべてのテストを一括実行できます。

個別のテストファイルを実行するには、bin/rails testコマンドにそのテストケースを含むファイル名を渡します。

$ bin/rails test test/models/article_test.rb
Run options: --seed 1559

# Running:

..

Finished in 0.027034s, 73.9810 runs/s, 110.9715 assertions/s.

2 runs, 3 assertions, 0 failures, 0 errors, 0 skips

上を実行すると、そのテストケースに含まれるメソッドがすべて実行されます。

あるテストケースの特定のテストメソッドだけを実行するには、-n（または--name）フラグでテストのメソッド名を指定します。

$ bin/rails test test/models/article_test.rb -n test_the_truth
Run options: -n test_the_truth --seed 43583

# Running:

.

Finished tests in 0.009064s, 110.3266 tests/s, 110.3266 assertions/s.

1 tests, 1 assertions, 0 failures, 0 errors, 0 skips

行番号を指定すると、特定の行だけをテストできます。

$ bin/rails test test/models/article_test.rb:6 # run specific test and line

ディレクトリを指定すると、そのディレクトリ内のすべてのテストを実行できます。

$ bin/rails test test/controllers # run all tests from specific directory

テストランナーではこの他にも、「failing fast」やテスト終了時に必ずテストを出力するといったさまざまな機能が使えます。次を実行してテストランナーのドキュメントをチェックしてみましょう。

$ bin/rails test -h
minitest options:
    -h, --help                       Display this help.
    -s, --seed SEED                  Sets random seed. Also via env. Eg: SEED=n rake
    -v, --verbose                    Verbose. Show progress processing files.
    -n, --name PATTERN               Filter run on /regexp/ or string.
        --exclude PATTERN            Exclude /regexp/ or string from run.

Known extensions: rails, pride

Usage: bin/rails test [options] [files or directories]
You can run a single test by appending a line number to a filename:

    bin/rails test test/models/user_test.rb:27

You can run multiple files and directories at the same time:

    bin/rails test test/controllers test/integration/login_test.rb

By default test failures and errors are reported inline during a run.

Rails options:
    -w, --warnings                   Run with Ruby warnings enabled
    -e, --environment                Run tests in the ENV environment
    -b, --backtrace                  Show the complete backtrace
    -d, --defer-output               Output test failures and errors after the test run
    -f, --fail-fast                  Abort test run on first failure or error
    -c, --[no-]color                 Enable color in the output

3 テストデータベース

Railsアプリは、ほぼ間違いなくデータベースと密接なやりとりを行いますので、テスティングにもデータベースが必要となります。効率のよいテストを作成するには、データベースの設定方法とサンプルデータの導入方法を理解しておく必要があります。

デフォルトでは、すべてのRailsアプリにはdevelopment、test、productionの3つの環境があります。それぞれの環境におけるデータベース設定はconfig/database.ymlで行います。

テスティング専用のデータベースを用いることで、それを設定して他の環境から切り離された専用のテストデータにアクセスできます。これにより、development環境やproduction環境のデータベースにあるデータを気にすることなく確実なテストを実行できます。

3.1 テストデータベースのスキーマを管理する

テストを実行するには、テストデータベースが最新の状態で構成されている必要があります。テストヘルパーは、テストデータベースに未完了のマイグレーションが残っていないかどうかをチェックします。マイグレーションがすべて終わっている場合、db/schema.rbやdb/structure.sqlをテストデータベースに読み込みます。ペンディングされたマイグレーションがある場合、エラーが発生します。このエラーが発生するということは、スキーマのマイグレーションが不完全であることを意味します。developmentデータベースに対してマイグレーション（bin/rails db:migrate）を実行することで、スキーマが最新の状態になります。

3.2 フィクスチャのしくみ

よいテストを作成するにはよいテストデータを準備する必要があることを理解しておく必要があります。 Railsでは、テストデータの定義とカスタマイズはフィクスチャで行うことができます。 網羅的なドキュメントについては、フィクスチャAPIドキュメントを参照してください。

3.2.1 フィクスチャとは何か

フィクスチャ (fixture)とは、いわゆるサンプルデータを言い換えたものです。フィクスチャを使用することで、事前に定義したデータをテスト実行直前にtestデータベースに導入することができます。フィクスチャはYAMLで記述され、特定のデータベースに依存しません。1つのモデルにつき1つのフィクスチャファイルが作成されます。

フィクスチャファイルはtest/fixturesの下に置かれます。rails generate modelを実行してモデルを新規作成すると、モデルのフィクスチャスタブが自動的に作成され、このディレクトリに置かれます。

3.2.2 YAML

YAML形式のフィクスチャは人間にとってとても読みやすく、サンプルデータを容易に記述することができます。この形式のフィクスチャには.ymlというファイル拡張子が与えられます (users.ymlなど)。

YAMLフィクスチャファイルのサンプルを以下に示します。

# この行はYAMLのコメントである
david:
  name: David Heinemeier Hansson
  birthday: 1979-10-15
  profession: Systems development

steve:
  name: Steve Ross Kellock
  birthday: 1974-09-27
  profession: guy with keyboard

各フィクスチャは名前とコロンで始まり、その後にコロンで区切られたキー/値ペアのリストがインデント付きで置かれます。通常、レコード間は空行で区切られます。行の先頭に#文字を置くことで、フィクスチャファイルにコメントを追加できます。'yes'や'no'などのYAMLキーワードに似たキーについては、引用符で囲むことでYAMLパーサーが正常に動作できます。

関連付けを使用している場合は、2つの異なるフィクスチャの間に参照ノードを1つ定義すれば済みます。belongs_to/has_many関連付けの例を以下に示します。

# fixtures/categories.ymlの内容:
about:
  name: About

# fixtures/articles.ymlの内容
first:
  title: Welcome to Rails!
  body: Hello world!
  category: about

fixtures/articles.ymlファイル内のfirstの記事にあるcategoryキーの値がaboutになっていることにご注目ください。これはfixtures/categories.yml内のaboutカテゴリを読み込むようRailsに指示するためのものです。

3.2.3 ERB

ERBは、テンプレート内にRubyコードを埋め込むのに使用されます。YAMLフィクスチャ形式のファイルは、Railsに読み込まれたときにERBによる事前処理が行われます。ERBを活用すれば、Rubyで一部のサンプルデータを生成できます。たとえば、以下のコードを使用すれば1000人のユーザーを生成できます。

<% 1000.times do |n| %>
user_<%= n %>:
  username: <%= "user#{n}" %>
  email: <%= "user#{n}@example.com" %>
<% end %>

3.2.4 フィクスチャの動作

Railsはデフォルトで、test/fixturesフォルダにあるすべてのフィクスチャを自動的に読み込み、モデルやコントローラのテストで使用します。フィクスチャの読み込みは主に以下の3つの手順からなります。

1. フィクスチャに対応するテーブルに含まれている既存のデータをすべて削除する
2. フィクスチャのデータをテーブルに読み込む
3. フィクスチャに直接アクセスしたい場合はフィクスチャのデータをメソッドにダンプする

3.2.5 フィクスチャはActive Recordオブジェクト

フィクスチャは、実はActive Recordのインスタンスです。前述の3番目の手順にもあるように、フィクスチャはスコープがテストケースのローカルになっているメソッドを自動的に利用可能にしてくれるので、フィクスチャのオブジェクトに直接アクセスできます。以下に例を示します。

# davidという名前のフィクスチャに対応するUserオブジェクトを返す
users(:david)

# idで呼び出されたdavidのプロパティを返す
users(:david).id

# Userクラスで利用可能なメソッドにアクセスすることもできる
david = users(:david)
david.call(david.partner)

複数のフィクスチャを一括で取得するには、次のようにフィクスチャ名をリストで渡します。

# this will return an array containing the fixtures david and steve
users(:david, :steve)

4 モデルテスト

モデルのテストは、アプリのさまざまなモデルをテストするのに遣われます。

Railsのモデルテストはtest/modelsディレクトリの下に保存されます。Railsではモデルテストのスケルトンを生成するジェネレータが提供されています。

$ bin/rails generate test_unit:model article title:string body:text
create  test/models/article_test.rb
create  test/fixtures/articles.yml

モデルテストにはActionMailer::TestCaseのような独自のスーパークラスがなく、代わりにActiveSupport::TestCaseを継承します。

5 システムテスト

システムテストはアプリのユーザー操作のテストに使えます。テストは、実際のブラウザまたはヘッドレスブラウザに対して実行されます。システムテストではそのために背後でCapybaraを使います。

アプリのtest/systemディレクトリは、Railsのシステムテストを作成するために使います。Railsではシステムテストのスケルトンを生成するジェネレータが提供されています。

$ bin/rails generate system_test users
      invoke test_unit
      create test/system/users_test.rb

生成直後のシステムテストは次のようになっています。

require "application_system_test_case"

class UsersTest < ApplicationSystemTestCase
  # test "visiting the index" do
  #   visit users_url
  #
  #   assert_selector "h1", text: "Users"
  # end
end

システムテストでは、デフォルトでSeleniumドライバと画面サイズ1400x1400のChromeブラウザを用いて実行されます。次のセクションで、デフォルト設定の変更方法について説明します。

5.1 デフォルト設定の変更

Railsのシステムテストのデフォルト設定変更方法は非常にシンプルです。すべての設定が抽象化されているので、テストの作成に集中できます。

新しいアプリやscaffoldを生成すると、そのテストのディレクトリにapplication_system_test_case.rbファイルが作成されます。システムテストの設定はすべてここで行います。

デフォルト設定を変更したい場合は、システムテストのdriven_by項目を変更できます。たとえばドライバをSeleniumからPoltergeistに変更する場合は、まずpoltergeist gemをGemfileに追加し、続いてapplication_system_test_case.rbを以下のように変更します。

require "test_helper"
require "capybara/poltergeist"

class ApplicationSystemTestCase < ActionDispatch::SystemTestCase
  driven_by :poltergeist
end

このドライバ名はdriven_byで必要な引数です。driven_byに渡せるオプション引数としては、他に:using（ブラウザを指定する、Seleniumでのみ有効）や:screen_size（スクリーンショットのサイズ変更）、:options（ドライバでサポートされるオプションの指定）があります。

require "test_helper"

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

ヘッドレスブラウザを使いたい場合は、:using引数にheadless_chromeを追加します。

require "test_helper"

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

Railsで提供されていないCapybara設定が必要な場合は、application_system_test_case.rbファイルに設定を追加できます。

追加設定についてはCapybaraのドキュメントを参照してください。

5.2 スクリーンショットヘルパー

ScreenshotHelperは、テスト中のスクリーンショットをキャプチャするよう設計されたヘルパーで、テストが失敗した時点のブラウザ画面を確認するときや、デバッグでスクリーンショットを確認するときに有用です。

take_screenshotメソッドおよびtake_failed_screenshotメソッドが提供されており、take_failed_screenshotはRails内部のafter_teardownに自動的に含まれます。

take_screenshotヘルパーメソッドはテストのどこにでも書くことができ、ブラウザのスクリーンショット撮影に使えます。

5.3 システムテストを実装する

それではブログアプリにシステムテストを追加することにしましょう。システムテストで最初にindexページを表示し、新しいブログ記事を1件作成します。

scaffoldジェネレータを使った場合はシステムテストのスケルトンが自動で作成されています。scaffoldジェネレータを使わなかった場合はシステムテストのスケルトンを自分で作成しておきましょう。

$ bin/rails generate system_test articles

上のコマンドを実行するとテストファイルのプレースホルダが作成され、次のように表示されるはずです。

      invoke  test_unit
      create    test/system/articles_test.rb

それではこのファイルを開いて最初のアサーションを書きましょう。

require "application_system_test_case"

class ArticlesTest < ApplicationSystemTestCase
  test "viewing the index" do
    visit articles_path
    assert_selector "h1", text: "Articles"
  end
end

このテストは記事のindexページにh1が存在していればパスします。

システムテストを実行します。

bin/rails test:system

5.3.1 記事のシステムテストを作成する

それではブログで新しい記事を作成するフローをテストしましょう。

test "creating an article" do
  visit articles_path

  click_on "New Article"

  fill_in "Title", with: "Creating an Article"
  fill_in "Body", with: "Created this article successfully!"

  click_on "Create Article"

  assert_text "Creating an Article"
end

最初の手順ではvisit articles_pathを呼び出し、記事のindexページの表示をテストします。

続いてclick_on "New Article"でindexページの「New Article」ボタンを検索します。するとブラウザが/articles/newにリダイレクトされます。

次に記事のタイトルと本文に指定のテキストを入力しています。フィールドへの入力が終わったら「Create Article」をクリックして、データベースに新しい記事を作成するPOSTリクエストを送信しています。

そして記事の元のindexページにリダイレクトされ、新しい記事のタイトルがその記事のindexページに表示されます。

5.3.2 システムテストを使いこなす

システムテストの長所は、ユーザーによるやり取りをコントローラやモデルやビューを用いてテストできるという点で結合テストに似ていますが、本物のユーザーが操作しているかのようにテストを実際に実行できるためずっと頑丈です。ユーザーがアプリで行える操作であれば、コメント入力や記事の削除、ドラフト記事の公開など何でも行えます。

6 結合テスト

結合テスト (integration test) は、複数のコントローラ同士のやりとりをテストします。一般に、アプリ内の重要なワークフローのテストに使用されます。

Railsの結合テストは、アプリのtest/integrationディレクトリに作成します。Railsでは結合テストのスケルトンを生成するジェネレータが提供されています。

$ bin/rails generate integration_test user_flows
      exists  test/integration/
      create  test/integration/user_flows_test.rb

生成直後の結合テストは以下のような内容になっています。

require 'test_helper'

class UserFlowsTest < ActionDispatch::IntegrationTest
  # test "the truth" do
  #   assert true
  # end
end

結合テストはActionDispatch::IntegrationTestから継承されます。これにより、結合テスト内でさまざまなヘルパーが利用できます。

6.1 結合テストで使用できるヘルパー

システムテストでは、標準のテストヘルパー以外にもActionDispatch::IntegrationTestから継承されるいくつかのヘルパーを利用できます。その中から3つのカテゴリについて簡単にご紹介します。

結合テストランナーについてはActionDispatch::Integration::Runnerを参照してください。

リクエストの実行についてはActionDispatch::Integration::RequestHelpersにあるヘルパーを用いることにします。

セッションを改変する必要がある場合や、結合テストのステートを変更する必要がある場合は、ActionDispatch::Integration::Sessionを参照してください。

6.2 結合テストを実装する

それではブログアプリに結合テストを追加することにしましょう。最初に基本的なワークフローととして新しいブログ記事を1件作成し、すべて問題なく動作することを確認します。

まずは結合テストのスケルトンを生成します。

$ bin/rails generate integration_test blog_flow

上のコマンドを実行するとテストファイルのプレースホルダが作成され、次のように表示されるはずです。

      invoke  test_unit
      create    test/integration/blog_flow_test.rb

それではこのファイルを開いて最初のアサーションを書きましょう。

require 'test_helper'

class BlogFlowTest < ActionDispatch::IntegrationTest
  test "can see the welcome page" do
    get "/"
    assert_select "h1", "Welcome#index"
  end
end

リクエストで生成されるHTMLをテストするassert_selectについてはこの後の「ビューをテストする」で言及します。これはリクエストに対するレスポンスのテストに用いるもので、重要なHTML要素がコンテンツに存在するというアサーションを行います。

rootパスを表示すると、そのビューでwelcome/index.html.erbが表示されるはずなので、このアサーションはパスするはずです。

6.2.1 記事の結合テストを作成する

ブログに新しい記事を1件作成して、生成された記事が表示できていることをテストしましょう。

test "can create an article" do
  get "/articles/new"
  assert_response :success

  post "/articles",
    params: { article: { title: "can create", body: "article successfully." } }
  assert_response :redirect
  follow_redirect!
  assert_response :success
  assert_select "p", "Title:\n  can create"
end

理解のため、このテストを細かく分けてみましょう。

最初にArticlesコントローラの:newアクションを呼びます。このレスポンスは成功するはずです。

次にArticlesコントローラの:createアクションを呼びます。

post "/articles",
  params: { article: { title: "can create", body: "article successfully." } }
assert_response :redirect
follow_redirect!

その次の2行では、記事が1件作成されるときのリクエストのリダイレクトを扱います。

最後は、レスポンスが成功して記事がページ上で読める状態になっているというアサーションです。

6.2.2 結合テストを使いこなす

ブログを表示して記事を1件作成するという、きわめて小規模なワークフローを無事テストできました。このテストにコメントを追加するもよし、記事の削除や編集のテストを行うもよしです。結合テストは、アプリのあらゆるユースケースに伴うエクスペリエンスのテストに向いています。

7 コントローラの機能テスト

Railsで1つのコントローラに含まれる複数のアクションをテストを作成することを、「コントローラに対する機能テスト (functional test) を作成する」と呼んでいます。コントローラはアプリが受け付けたWebリクエストを処理し、レンダリングされたビューの形で最終的なレスポンスを返すことを思い出しましょう。機能テストでは、アクションがリクエストや期待される結果（レスポンス、場合によってはHTMLビュー）をどう扱っているかをテストします。

7.1 機能テストに含める項目

機能テストでは以下のようなテスト項目を実施する必要があります。

• Webリクエストが成功したか
• 正しいページにリダイレクトされたか
• ユーザー認証が成功したか
• レスポンスのテンプレートに正しいオブジェクトが保存されたか
• ビューに表示されたメッセージは適切か

実際の機能テストを最も簡単に見る方法は、scaffoldジェネレータでコントローラを生成することです。

$ bin/rails generate scaffold_controller article title:string body:text
...
create  app/controllers/articles_controller.rb
...
invoke  test_unit
create    test/controllers/articles_controller_test.rb
...

Articleリソースのコントローラコードとテストが生成され、test/controllersにあるarticles_controller_test.rbファイルを見ることができるようになります。

既にコントローラがあり、7つのデフォルトのアクションごとにテスト用のscaffoldコードだけを生成したい場合は、以下のコマンドを実行します。

$ bin/rails generate test_unit:scaffold article
...
invoke  test_unit
create    test/controllers/articles_controller_test.rb
...

articles_controller_test.rbファイルのtest_should_get_indexというテストについて見てみます。

# articles_controller_test.rb
class ArticlesControllerTest < ActionDispatch::IntegrationTest
   test "should get index" do
     get articles_url
     assert_response :success
  end
end

test_should_get_indexというテストでは、Railsがindexという名前のアクションに対するリクエストをシミュレートします。同時に、有効なarticlesインスタンス変数がコントローラに割り当てられます。

getメソッドはWebリクエストを開始し、結果を@responseとして返します。このメソッドには以下の6つの引数を渡すことができます。

• リクエストするコントローラアクションのURI。 これは文字列ヘルパーかルーティングヘルパーの形を取る（articles_urlなど）。
• params: アクションに渡すリクエストパラメータのハッシュ（クエリの文字列パラメータまたはarticle変数など）。
• headers: リクエストで渡されるヘッダーの設定に用いる。
• env: リクエストの環境を必要に応じてカスタマイズするのに用いる。
• xhr: リクエストがAjaxかどうかを指定する。Ajaxの場合はtueを設定。
• as: 別のcontent typeでエンコードされているリクエストに用いる。デフォルトで:jsonをサポート。

上のキーワード引数はすべてオプションです。

例: :showアクションを呼び出し、idに12を指定してparamsとして渡し、HTTP_REFERERヘッダを設定する。

get article_url, params: { id: 12 }, headers: { "HTTP_REFERER" => "http://example.com/home" }

別の例: :updateアクションを呼び出し、idに12を指定し、Ajaxのリクエストのparamsとして渡す。

patch article_url, params: { id: 12 }, xhr: true

articles_controller_test.rbファイルのtest_should_create_articleテストを変更して、テストがパスするようにしてみましょう。

test "should create article" do
  assert_difference('Article.count') do
    post articles_url, params: { article: { body: 'Rails is awesome!', title: 'Hello Rails' } }
  end

  assert_redirected_to article_path(Article.last)
end

これで、すべてのテストを実行するとパスするようになったはずです。

request.headers['Authorization'] = ActionController::HttpAuthentication::Basic.
  encode_credentials('dhh', 'secret')

7.2 機能テストで利用できるHTTPリクエストの種類

HTTPリクエストに精通していれば、getがHTTPリクエストの一種であることも既に理解していることでしょう。Railsの機能テストでは以下の6種類のHTTPリクエストがサポートされています。

• get
• post
• patch
• put
• head
• delete

これらはすべてメソッドとして利用できます。典型的なCRUDアプリでよく使われるのはget、post、put、deleteです。

7.3 XHR（AJAX）リクエストをテストする

get、post、patch、put、 deleteメソッドで次のようにxhr: trueを指定することで、AJAXリクエストをテストできます。

test "ajax request" do
  article = articles(:one)
  get article_url(article), xhr: true

  assert_equal 'hello world', @response.body
  assert_equal "text/javascript", @response.content_type
end

7.4 「黙示的な」3つのハッシュ

リクエストが完了して処理されると、以下の3つのハッシュオブジェクトが利用可能になります。

• cookies - 設定されているすべてのcookies。
• flash - flash内のすべてのオブジェクト。
• session - セッション変数に含まれるすべてのオブジェクト。

これらのハッシュは、通常のHashオブジェクトと同様に文字列をキーとして値を参照できます。たとえば次のようにシンボル名による参照も可能です。

flash["gordon"]               flash[:gordon]
session["shmession"]          session[:shmession]
cookies["are_good_for_u"]     cookies[:are_good_for_u]

7.5 利用可能なインスタンス変数

機能テストでは、1つのリクエストの完了ごとに以下の3つの専用インスタンス変数を使用できます。

• @controller - リクエストを処理するコントローラ
• @request - リクエストオブジェクト
• @response - レスポンスオブジェクト

class ArticlesControllerTest < ActionDispatch::IntegrationTest
  test "should get index" do
    get articles_url

    assert_equal "index", @controller.action_name
    assert_equal "application/x-www-form-urlencoded", @request.media_type
    assert_match "Articles", @response.body
  end
end

7.6 HTTPとヘッダーとCGI変数を設定する

HTTPヘッダーとCGI変数はヘッダーとして渡されます。

# HTTPヘッダーを設定する
get articles_url, headers: { "Content-Type": "text/plain" } # simulate the request with custom header

# CGI変数を設定する
get articles_url, headers: { "HTTP_REFERER": "http://example.com/home" } # simulate the request with custom env variable

7.7 flash通知をテストする

上述の「黙示的な」3つのヘッダーの1つがflashです。

誰かがこのブログアプリで記事を1件作成するのに成功したらflashメッセージを追加したいと思います。

このアサーションをtest_should_create_articleテストに追加してみましょう。

test "should create article" do
  assert_difference('Article.count') do
    post article_url, params: { article: { title: 'Some title' } }
  end

  assert_redirected_to article_path(Article.last)
  assert_equal 'Article was successfully created.', flash[:notice]
end

この時点でテストを実行すると、以下のように失敗するはずです。

$ bin/rails test test/controllers/articles_controller_test.rb -n test_should_create_article
Run options: -n test_should_create_article --seed 32266

# Running:

F

Finished in 0.114870s, 8.7055 runs/s, 34.8220 assertions/s.

  1) Failure:
ArticlesControllerTest#test_should_create_article [/test/controllers/articles_controller_test.rb:16]:
--- expected
+++ actual
@@ -1 +1 @@
-"Article was successfully created."
+nil

1 runs, 4 assertions, 1 failures, 0 errors, 0 skips

今度はコントローラにflashメッセージを実装してみましょう。:createアクションは次のようになります。

def create
  @article = Article.new(article_params)

  if @article.save
    flash[:notice] = 'Article was successfully created.'
    redirect_to @article
  else
    render 'new'
  end
end

テストを実行すると、今度はパスするはずです。

$ bin/rails test test/controllers/articles_controller_test.rb -n test_should_create_article
Run options: -n test_should_create_article --seed 18981

# Running:

.

Finished in 0.081972s, 12.1993 runs/s, 48.7972 assertions/s.

1 runs, 4 assertions, 0 failures, 0 errors, 0 skips

7.8 テストをまとめて行う

この時点でのArticlesコントローラの:indexアクションは:newや:createと同様にテストされるようになりました。既存のデータの扱いはどう書くのでしょうか？

:showアクションのテストを書いてみましょう。

test "should show article" do
  article = articles(:one)
  get article_url(article)
  assert_response :success
end

記事の削除は次のようにテストします。

test "should destroy article" do
  article = articles(:one)
  assert_difference('Article.count', -1) do
    delete article_url(article)
  end
  assert_redirected_to articles_path
end

既存の記事の更新も次のように書けます。

test "should update article" do
  article = articles(:one)

  patch article_url(article), params: { article: { title: "updated" } }

  assert_redirected_to article_path(article)
  # 更新されたデータをフェッチするために関連付けをリロードし、タイトルが更新されたというアサーションを行う
  article.reload
  assert_equal "updated", article.title
end

3つのテストは、どれも同じArticleフィクスチャデータへのアクセスを行っており、少々重複していますので、DRYにしましょう。これはActiveSupport::Callbacksが提供するsetupメソッドとteardownメソッドで行います。

ここまでで、テストは次のようになっているはずです。残りのテストはとりあえずこのままにしておくことにします。

require 'test_helper'
class ArticlesControllerTest < ActionDispatch::IntegrationTest
  # 各テストの実行前に呼ばれる
  setup do
    @article = articles(:one)
  end  

  # 各テストの実行後に呼ばれる
  teardown do
    # コントローラがキャッシュを使っている場合、テスト後にリセットしておくとよい
    Rails.cache.clear
  end

  test "should show article" do
    # セットアップ時の@articleインスタンス変数を再利用
    get article_url(@article)
    assert_response :success
  end

  test "should destroy article" do
    assert_difference('Article.count', -1) do
      delete article_url(@article)
    end
    assert_redirected_to articles_path
  end

  test "should update article" do
    patch article_url(@article), params: { article: { title: "updated" } }

    assert_redirected_to article_path(@article)
    # 更新されたデータをフェッチするために関連付けをリロードし、タイトルが更新されたというアサーションを行う
    @article.reload
    assert_equal "updated", @article.title
  end
end

Railsの他のコールバックと同様、setupメソッドとteardownメソッドにブロックやlambdaを渡したりメソッド名のシンボルで呼び出すこともできます。

7.9 テストヘルパー

コードの重複を回避するために独自のテストヘルパーを追加できます。サインインヘルパーはその良い例です。

# test/test_helper.rb

module SignInHelper
  def sign_in_as(user)
    post sign_in_url(email: user.email, password: user.password)
  end
end

class ActionDispatch::IntegrationTest
  include SignInHelper
end

require 'test_helper'
class ProfileControllerTest < ActionDispatch::IntegrationTest

  test "should show profile" do
    # ヘルパーがどのコントローラテストケースでも再利用可能になっている
    sign_in_as users(:david)

    get profile_url
    assert_response :success
  end
end     

8 ルーティングをテストする

Railsアプリの他のあらゆる部分と同様、ルーティングもテストできます。ルーティングのテストはtest/controllers/に配置するか、コントローラテストの一部として書きます。

Railsで使えるルーティングアサーションについて詳しくは、ActionDispatch::Assertions::RoutingAssertionsのAPIドキュメントを参照してください。

9 ビューをテストする

リクエストに対するレスポンスをテストするために、あるページで重要なHTML要素とその内容がレスポンスに含まれているアサーションを書くのはアプリのビューのテストでよく行われることです。assert_selectというアサーションを使用すると、こうしたテストで簡潔かつ強力な文法を利用できるようになります。

assert_selectには2つの書式があります。

assert_select(セレクタ, [条件], [メッセージ])という書式は、セレクタで指定された要素が条件に一致することを主張します。セレクタにはCSSセレクタの式 (文字列) や代入値を持つ式を使用できます。

assert_select(要素, セレクタ, [条件], [メッセージ]) は、選択されたすべての要素が条件に一致することを主張します。選択される要素は、element (Nokogiri::XML::Node or Nokogiri::XML::NodeSetのインスタンス) からその子孫要素までの範囲から選択されます。

たとえば、レスポンスに含まれるtitle要素の内容を検証するには、以下のアサーションを使用します。

assert_select 'title', "Welcome to Rails Testing Guide"

より詳しくテストするために、ネストしたassert_selectブロックを用いることもできます。

以下の例の場合、外側のassert_selectで選択されたすべての要素の完全なコレクションに対して、内側のassert_selectがアサーションを実行します。

assert_select 'ul.navigation' do
  assert_select 'li.menu_item'
end

選択された要素のコレクションをイテレート (列挙) し、assert_selectが要素ごとに呼び出されるようにすることもできます。

たとえば、レスポンスに2つの順序付きリストがあり、1つの順序付きリストにつき要素が4つあれば、以下のテストはどちらもパスします。

assert_select "ol" do |elements|
  elements.each do |element|
    assert_select element, "li", 4
  end
end

assert_select "ol" do
  assert_select "li", 8
end

assert_selectはきわめて強力なアサーションです。このアサーションの高度な利用法についてはドキュメントを参照してください。

9.1 その他のビューベースのアサーション

主にビューをテストするためのアサーションは他にもあります。

assert_select_emailの利用例を以下に示します。

assert_select_email do
  assert_select 'small', 'オプトアウトしたい場合は "購読停止" をクリックしてください。'
end

10 ヘルパーをテストする

ヘルパー自体は単なるシンプルなモジュールであり、ビューから利用するヘルパーメソッドをこの中に定義します。

ヘルパーのテストについては、ヘルパーメソッドの出力が期待どおりであるかどうかをチェックするだけで十分です。ヘルパー関連のテストはtest/helpersディレクトリに置かれます。

以下のようなヘルパーがあるとします。

module UserHelper
  def link_to_user(user)
    link_to "#{user.first_name} #{user.last_name}", user
  end
end

このメソッドの出力は次のようにしてテストできます。

class UserHelperTest < ActionView::TestCase
  test "should return the user's full name" do
    user = users(:david)

    assert_dom_equal %{<a href="/user/#{user.id}">David Heinemeier Hansson</a>}, link_to_user(user)
  end
end

さらに、テストクラスはActionView::TestCaseをextendしたものなので、link_toやpluralizeなどのRailsヘルパーメソッドにアクセスできます。

11 メイラーをテストする

メイラークラスを十分にテストするためには特殊なツールが若干必要になります。

11.1 メイラーのテストについて

Railsアプリの他の部分と同様、メイラークラスについても期待どおり動作するかどうかをテストする必要があります。

メイラークラスをテストする目的は以下を確認することです。

• メールが処理 (作成および送信) されていること
• メールの内容 (subject、sender、bodyなど) が正しいこと
• 適切なメールが適切なタイミングで送信されていること

11.1.1 あらゆる側面からのチェック

メイラーのテストには単体テストと機能テストの2つの側面があります。単体テストでは、完全に制御された入力を与えた結果の出力と、期待される既知の値 (フィクスチャー) とを比較します。機能テストではメイラーによって作成される詳細部分についてのテストはほとんど行わず、コントローラとモデルがメイラーを正しく利用しているかどうかをテストするのが普通です。メイラーのテストは、最終的に適切なメールが適切なタイミングで送信されたことを立証するために行います。

11.2 単体テスト

メイラーが期待どおりに動作しているかどうかをテストするために、事前に作成しておいた出力例と、メイラーの実際の出力を比較するという単体テストを行なうことができます。

11.2.1 フィクスチャーの逆襲

メイラーの単体テストを行なうために、フィクスチャーを利用してメイラーが最終的に出力すべき外見の例を与えます。これらのフィクスチャーはメールの出力例であって、通常のフィクスチャーのようなActive Recordデータではないので、通常のフィクスチャーとは別の専用のサブディレクトリに保存します。test/fixturesディレクトリの下のディレクトリ名は、メイラーの名前に対応させてください。たとえばUserMailerという名前のメイラーであれば、test/fixtures/user_mailerというスネークケースのディレクトリ名にします。

メイラーを生成すると、メイラーの各アクションに対応するスタブフィクスチャーが生成されます。Railsのジェネレータを使用しない場合は、自分でこれらのファイルを作成する必要があります。

11.2.2 基本的なテストケース

inviteというアクションで知人に招待状を送信するUserMailerという名前のメイラーに対する単体テストを以下に示します。これは、inviteアクションをジェネレータで生成したときに作成される基本的なテストに手を加えたものです。

require 'test_helper'

class UserMailerTest < ActionMailer::TestCase
  test "invite" do
    # さらにアサーションを行うためにメールを作成して保存
    email = UserMailer.create_invite('me@example.com',
                                     'friend@example.com', Time.now)

    # メールを送信後キューに追加されるかどうかをテスト
    assert_emails 1 do
      email.deliver_now
    end

    # 送信されたメールの本文が期待どおりの内容であるかどうかをテスト
    assert_equal ['me@example.com'], email.from
    assert_equal ['friend@example.com'], email.to
    assert_equal 'You have been invited by me@example.com', email.subject
    assert_equal read_fixture('invite').join, email.body.to_s
  end
end

このテストでは、メールを送信し、その結果返されたオブジェクトをemail変数に保存します。続いて、このメールが送信されたことを主張します (最初のアサーション)。次のアサーションでは、メールの内容が期待どおりであることを主張します。read_fixtureヘルパーを使用してこのファイルの内容を読みだしています。

inviteフィクスチャーは以下のような内容にしておきます。

friend@example.comさん、こんにちは。

招待状を送付いたします。

どうぞよろしく!

ここでメイラーのテスト作成方法の詳細部分についてご説明したいと思います。config/environments/test.rbのActionMailer::Base.delivery_method = :testという行で送信モードをtestに設定しています。これにより、送信したメールが実際に配信されないようにできます。そうしないと、テスト中にユーザーにスパムメールを送りつけてしまうことになります。この設定で送信したメールは、ActionMailer::Base.deliveriesという配列に追加されます。

11.3 機能テスト

メイラーの機能テストでは、メール本文や受取人が正しいことを確認するなど、単体テストでカバーされているようなことは扱いません。メールの機能テストでは、メール配信メソッドを呼び出し、その結果適切なメールが配信リストに追加されるかどうかをチェックします。機能テストでは配信メソッド自体は正常に動作すると仮定することになりますが、これでまず問題ありません。機能テストでは、期待されたタイミングでアプリのビジネスロジックからメールが送信されるかどうかをテストすることがメインになるのが普通だからです。たとえば、友人を招待するという操作によってメールが適切に送信されるかどうかをチェックするには以下のような機能テストを使用します。

require 'test_helper'

class UserControllerTest < ActionDispatch::IntegrationTest
  test "invite friend" do
    assert_difference 'ActionMailer::Base.deliveries.size', +1 do
      post invite_friend_url, params: { email: 'friend@example.com' }
    end
    invite_email = ActionMailer::Base.deliveries.last

    assert_equal "You have been invited by me@example.com", invite_email.subject
    assert_equal 'friend@example.com', invite_email.to[0]
    assert_match(/Hi friend@example\.com/, invite_email.body.to_s)
  end
end

12 ジョブをテストする

カスタムジョブはアプリ内部のさまざまなレベルでキューイングされるため、ジョブそのもの（キューイングされるときの振る舞い）とその他のエンティティが正常にキューイングされるかどうかを両方テストする必要があります。

12.1 基本のテストケース

デフォルトではジョブを1つ作成すると、ジョブに関連するテストがtest/jobsディレクトリの下にも生成されます。以下は請求ジョブの例です。

require 'test_helper'

class BillingJobTest < ActiveJob::TestCase
  test 'that account is charged' do
    BillingJob.perform_now(account, product)
    assert account.reload.charged_for?(product)
  end
end

このテストは、ジョブが期待どおり動作したというアサーションのみを行うかなりシンプルなものです。

デフォルトではActiveJob::TestCaseがキューアダプタを:testに設定してジョブがインラインで実行されるようにします。また、それまでに実行されキューイングされたジョブを各テスト前にすべてクリアして、各テストのスコープ内で既に実行されたジョブが存在しないというアサーションを安全に行えるようにします。

12.2 カスタムアサーションと他のコンポーネント内のジョブのテスト

Active Jobには、テストをシンプルに書くためのカスタムアサーションが多数付属しています。利用できるアサーションの全リストについては、ActiveJob::TestHelperのAPIドキュメントを参照してください。

（コントローラなどでの）呼び出しのたびにジョブが正しくキューイングまたは実行されているかをテストするのはよい練習になります。これこそActive Jobが提供するカスタムアサーションの出番です。次のモデルはその一例です。

require 'test_helper'

class ProductTest < ActiveJob::TestCase
  test 'billing job scheduling' do
    assert_enqueued_with(job: BillingJob) do
      product.charge(account)
    end
  end
end

13 その他のテスティング関連リソース

13.1 時間に依存するコードをテストする

Railsには、時間の影響を受けやすいコードが期待どおりに動作しているというアサーションに役立つ組み込みのヘルパーメソッドを提供しています。

以下の例ではtravel_toヘルパーを使っています。

# 登録後のユーザーは1か月分の特典が有効だとする
user = User.create(name: 'Gaurish', activation_date: Date.new(2004, 10, 24))
assert_not user.applicable_for_gifting?
travel_to Date.new(2004, 11, 24) do
  assert_equal Date.new(2004, 10, 24), user.activation_date # inside the `travel_to` block `Date.current` is mocked
  assert user.applicable_for_gifting?
end
assert_equal Date.new(2004, 10, 24), user.activation_date # The change was visible only inside the `travel_to` block.

時間関連のヘルパーについて詳しくは、ActiveSupport::Testing::TimeHelpers API Documentationを参照してください。