Rails7 テスト

前回作ったWordbook（リソースフル）のテストを書いてみます。 RailsのテストはminitestをRails用に拡張したものです。

• テストの種類
• モデルのテスト
  • フィクスチャ
  • モデルのテスト
  • テストの実行
• 機能テスト
  • HTTPメソッドをシミュレートするメソッド
  • ビューのテスト
• 結合テスト

テストの種類

Railsでは、4つのテストが用意されています。

• 単体テスト（unit test）
• 機能テスト（functional test）
• 結合テスト（integration test）
• システムテスト（system test）

今回の記事ではシステムテストを除いた3つのテストについて書きます。 システムテストは次回の記事で扱います。

日本語訳は書籍によって異なるかもしれません。 例えば「結合テスト」を「統合テスト」と訳すこともあります。 この記事の訳は「Railsガイド]に基づいています。

また、これらの用語は「一般論としてのテスト」にも使われますが、その使い方には幅があります。 Railsの場合は

• 「単体テスト」は主に「モデルのテスト」や「メーラーの単体テスト」
• 「機能テスト」は「コントローラのテスト」
• 「結合テスト」は「複数のアクションの間の流れのテスト」
• 「システムテスト」は「実際のクライアントとの通信に近い状況をシミュレートして行うテスト」

を指します。

モデルのテスト

モデルのテストでは

• データベースから読み出しが正しくできているか
• データベースに保存できているか
• バリデーションが正しく機能しているか

などをテストします。

これらは、コントローラやビューから切り離して単体でテストすることができます。 その意味では「単体テスト」です。 また、データベースまわりのテストが主になるので、そのためのいくつかの仕組みが用意されています。

フィクスチャ

フィクスチャはいわゆるサンプルデータです。 Yaml形式でデータを記述しておくと、Railsがテスト前にデータベースに保存してくれます。 /test/fixtures/words.ymlに2つほどサンプルデータを書いてみました。

# Word model fixtures

tall:
  en: tall
  jp: 高い
  note: |
    He is tall.
    彼は背が高い。

house:
  en: house
  jp: 家
  note: |
    I stayed in my house.
    私は家にいました。

Yamlはコロン（:）でキーと値のペアを表します。 Rubyのデータ構造でいえばハッシュにあたります。

{tall: {en: "tall", jp: "高い", note: "He is tall.\n彼は背が高い。\n"}}
{house: {en: "house", jp: "家", note: "I stayed in my house.\n私は家にいました。\n"}

Yamlの縦棒（|）は次の行からのデータが改行も含めてのデータであることを示します。 :tallと:houseはフィクスチャを指定するときの名前になります。 データベースに登録されるデータはenからnoteまでの部分です。

フィクスチャを変数に代入するには、そのモデル名の複数形を小文字で書いたメソッドを用います。

word = words(:tall)

これで変数wordにフィクスチャtallのモデルが代入されます。

モデルのテスト

モデルのテストは/test/models/word_test.rbに書きます。

require "test_helper"

class WordTest < ActiveSupport::TestCase
  test "fixture tall should be read" do
    word = Word.find_by(en: "tall")
    assert_equal "高い", word.jp
    assert_equal "He is tall.\n彼は背が高い。\n", word.note
  end

  test "A valid data should be saved uniquely" do
    w1 = Word.new(en: "room", jp: "部屋", note: "")
    w2 = Word.new(en: "room", jp: "空き", note: "")
    assert w1.save
    refute w2.save
  end

  test "three invalid data should not be saved" do
    w1 = Word.new(en: "", jp: "空き", note: "")
    w2 = Word.new(en: "@@@", jp: "アットマーク", note: "")
    w3 = Word.new(en: "page", jp: "", note: "Turn to page four.\n4ページを開きなさい。")
    [w1, w2, w3].each do |word|
      assert word.invalid?
      refute word.save
    end
  end
end

テストはWordTestクラスの定義の中に書きます。 クラスWordTestはActiveSupport::TestCaseのサブクラスです。 さらに、ActiveSupport::TestCaseはMinitest::Testのサブクラスです。 したがって、WordTestクラス内では、それらの祖先クラスのすべてのメソッドを使うことができます。

• Minitest::Testはminitestのクラス。 Minitest::Asertionsモジュールをインクルードしている。 minitestで使うアサーションはすべて使うことができる
• ActiveSupport::TestCaseはRailsのクラスでActiveSupport::Testing::Assertionsモジュールをインクルードしている。 そのモジュールにはRailsで追加した独自のアサーションが定義されている
  • assert_changes
  • assert_difference
  • assert_no_changes
  • assert_no_difference
  • assert_not
  • assert_nothing_raised

アサーションの詳細は上記のリンクやRails Guideを参照して下さい。 また、minitestについては本ブログにも記事があります。 カテゴリー（categories）の「minitest」をご覧ください。

クラス内の各テストを記述するのにtestメソッドを使っています。 これは「”test_“+引数」を名前にしたメソッドを定義します。 つまり、次の2つは同じことになります。

test "show hello" do
  print "Hello world.\n"
end

def test_show_hello
  print "Hello world.\n"
end

testメソッドの引数にはそのテストの内容や目的を書きます。 それによって、defステートメントよりも「テストらしくみえる」「テストの内容を示すことができる」ということが可能です。

2つめのテストを見てみましょう。 ここでは、assertとrefuteの2つのメソッドが使われています。 両者ともminitestのメソッドです。

• assert ⇒ 引数が真ならばテストをパス、偽ならばフェイル
• refute ⇒ 引数が偽ならばテストをパス、真ならばフェイル

テストがフェイルした場合は、そこでテストは打ち切られ、フェイルのメッセージが画面に出力されます。

test "A valid data should be saved uniquely" do
  w1 = Word.new(en: "room", jp: "部屋", note: "")
  w2 = Word.new(en: "room", jp: "空き", note: "")
  assert w1.save
  refute w2.save
end

w1とw2は英単語が同じで、オブジェクトとしては異なるWordオブジェクトです。 w1をデータベースにsaveメソッドで保存するのは成功しますので、w1.saveは真を返します。 assert w1.saveは成功するわけです。

次にw2を保存しようとすると、バリデーションに引っかかります。 英単語はユニーク、すなわちデータベース中にひとつしか許されませんので、w2は保存できません。 このときsaveメソッドは偽を返します。 refuteは引数が偽のときにパスするので、このテストも通過するはずです。

次に、1番めのテストを見てみましょう。 ここでは、あらかじめデータベースに保存されているフィクスチャの呼び出しをチェックしています。 assert_equalは2つの引数をとり、それらが==であるときにテストをパスします。 テストでは英単語がtallであるデータを読み出して、日本語訳（jp）と備考（note）がフィクスチャと一致するかをテストしています。

3つめのテストはバリデーションのテストです。

• 英単語（en）は空ではいけない
• 英単語（en）はアルファベットのみの文字列でなければいけない
• 日本語訳（jp）は空ではいけない

これらに違反するWordモデルを作成して、invalid?メソッドでインバリッドであるかをテストし、さらにsaveが失敗することをテストします。

このように、モデルのテストは主に

• 読み書きが正しくできるか
• バリデーションが正常に機能するか

を見ます。

より複雑なデータベースでは、テーブル間のリレーションが機能しているかどうかもテストします。 ここではそのような複雑なテストについては省略します。

テストの実行

テストの実行はコマンドラインから./bin/rails test （テストプログラム）の形で実行します。

$ ./bin/rails test test/models/word_test.rb
Running 3 tests in a single process (parallelization threshold is 50)
Run options: --seed 543

# Running:

...

Finished in 0.145926s, 20.5584 runs/s, 68.5281 assertions/s.
3 runs, 10 assertions, 0 failures, 0 errors, 0 skips

途中のドットはテストが成功したことを表します。 テストが3つあったのでドットも3つ表示されます。 もしテストがフェイルすればFが、テストプログラムに誤りがあればE（エラー）がドットの代わりに表示されます。

最後の行にテスト結果が出ています。

• 3 runs ⇒ 3つのテストを実行
• 10 assertions ⇒ 10個のアサーション（個別のテスト）を実行
• 0 failures ⇒ 0個のフェイル
• 0 errors ⇒ 0個のエラー

機能テスト

機能テスト（functional test）はコントローラの動作をテストします。 また、ルーティングとビューはコントローラと一体ですので、それらのテストもここで行うことができます。 テストは/test/controllers/words_contraller_test.rbに記述します。

ルーティングとコントローラのテストとしては

• HTTPリクエストに対して正しいコントローラとアクションが呼び出されているか
• コントローラが正しくHTTPレスポンスを返す、またはリダイレクトしているか
• その他

が考えられます。

また、ビューのテストとしては、正しいHTMLタグが必要数だけ出力されているか、が考えられます。

テスト全体を以下に示します。

require "test_helper"

class WordsControllerTest < ActionDispatch::IntegrationTest
  test "should get index" do
    get words_url
    assert_response :success
  end

  test "should get show" do
    get word_url(words(:tall))
    assert_response :success
    assert_select "nav a", {text: /変更|削除/, count: 2}
    assert_select "nav a.disabled", {text: /変更|削除/, count: 0}

    id = words(:tall).id+words(:house).id
    get word_url(id)
    assert_response :success
    assert_select "nav a.disabled", {text: /変更|削除/, count: 2}
    assert_equal "データベースにはid=#{id}のデータは登録されていません", flash.now[:alert]
  end

  test "should get new" do
    get new_word_url
    assert_response :success
  end

  test "should create word" do
    assert_difference("Word.count") do
      post words_url, params: { word: { en: "stop", jp: "止まる", note: "" } }
    end
    assert_redirected_to word_path(Word.last)
  end

  test "should get edit" do
    get edit_word_url(words(:tall))
    assert_response :success
  end

  test "should update word" do
    word = words(:tall)
    patch word_url(word), params: {word: {en: "tall", jp: "背が高い", note: ""}}
    assert_redirected_to word_path(word)
  end

  test "should delete word" do
    word = words(:tall)
    assert_difference("Word.count", -1) do
      delete word_url(words(:tall))
    end
    assert_redirected_to words_path
  end

  test "should get search" do
    get words_search_url, params: {search: "."}
    assert_response :success
  end
end

テストを記述するクラスはWordsControllerTestで、ActionDispatch::IntegrationTestのサブクラスです。 なお、このActionDispatch::IntegrationTestは機能テストのクラスのスーパークラスであるだけでなく、結合テストのクラスのスーパークラスにもなっています。 したがって、両テストで同じメソッドを使うことができます。 クラスの親子関係は次のようになります。

WordsControllerTest < ActionDispatch::IntegrationTest < ActiveSupport::TestCase < Minitest::Test

機能テストでは、アサーションが単体テストよりも増えています。

• ActionDispatch::Assertions::ResponseAssertions
  • assert_response
  • assert_redirect_to
• ActionDispatch::Assertions::RoutingAssertions
  • assert_generates
  • assert_recognizes
  • assert_routing

アサーションの詳細は上記のリンクまたはRails Guideを参照してください。

HTTPメソッドをシミュレートするメソッド

機能テストではHTTPメソッドをシミュレートするメソッドを使うことができます。 それらの名前はHTTPメソッドと同じです。 例えばgetはHTTPのGETメソッドをシミュレートします。

get パス名（URL）, オプション

の形で用います。 オプションではパラメータなどを渡すことができます。 詳細はAPIリファランスを参照してください。

indexアクションのテストを見てみましょう

test "should get index" do
  get words_url
  assert_response :success
end

getメソッドでwords_urlすなわちhttp://www.example.com/wordsにアクセスします。 なお、words_urlはRailsのヘルパーメソッドで、words_pathのような働きをします。 words_pathが絶対パス/wordsを返すのに対し、words_urlは絶対URLを返します。 他のルーティングprefixに対しても同様のXXX_urlメソッド（XXXはPrefix）を使うことができます。 なお、テストでは仮のホストとしてhttp://www.example.comが用いられています。

このアドレスにGETメソッドでアクセスするとindexアクションにルーティングされます。

assert_responseはHTTPレスポンスのステータスコードをチェックします。 :successは200番台のコードにマッチします。

このテストではindexアクションにアクセスすると200番台のステータスコードでデータが送られてくることを確認しました。 もちろん、もっと詳しくチェックすることも可能です。 例えば、HTMLで送られてくるタグや文字列をチェックすることもできます。 しかし、あまり細かくテストしても意味はありませんから、この程度でも十分だと思います。

getの他に、post、patch、deleteなどのメソッドがあり、それぞれPOST、PATCH、DELETEのHTTPメソッドのリクエストをシミュレートします。 postの例としてcreateアクションのテストを見てみましょう。

test "should create word" do
  assert_difference("Word.count") do
    post words_url, params: { word: { en: "stop", jp: "止まる", note: "" } }
  end
  assert_redirected_to word_path(Word.last)
end

createアクションへは、あらかじめnewアクションで送られたフォームにデータを書き入れたものをPOSTメソッドで送ります。 そのデータはparamsキーを持つハッシュの形で送ります。

word: { en: "stop", jp: "止まる", note: "" }

これは、word[en]が「stop」、word[jp]が「止まる」、word[note]が空文字列のパラメータを表します。 words_urlはhttp://www.example.com/wordsになり、ここにPOSTでアクセスするとcreateアクションにルーティングされます。

ここでは、assert_differenceメソッドでテストしています。 このメソッドは「ブロック実行後の引数の値」から「ブロック実行前の引数の値」を引いた数をチェックします。 デフォルトでは差が1です。 createアクションが実行されると、データベースのWordレコードが1つ増えますから、レコード数「Word.count」の差が1になります。 無事データが保存されればこのテストは通過します。

また、createアクションが成功するとリダイレクトが起こります。 最後に追加したWordモデルのshowアクションにリダイレクトされるので、そのアドレスword_path(Word.last)へのリダイレクトかどうかをチェックしています。 なお、アドレスにword_url(Word.last)を用いても構いません。

削除の場合も同様にassert_differenceを使い、差が-1になるかどうかをチェックします。

ビューのテスト

ビューをテストするにはassert_selectメソッドを使います。 このメソッドはRails guideに書かれていますが、APIリファランスには記述がありません。 このメソッドはRails::Dom::TestingというGemのメソッドです。

• Rubygems: Rails-Dom-Testing
• ドキュメント: Rails::Dom::Testing

これらの情報を参考にしてください。

assert_select CSSセレクタ [, テスト]

という形で使います。

第2引数の「テスト」を省略すると、そのセレクタがHTMLデータに存在すればテストは通過します。 「テスト」がある場合は、そのテスト結果によりパス、フェイルが決まります。 「テスト」は、ハッシュで与えるのが基本的です。

• :textキー ⇒ そのセレクタ内にある文字列。文字列または正規表現と比較
• :countキー ⇒ そのセレクタがHTML内にいくつあるかの数値

その他にもありますが、詳細はドキュメントを参照してください。 ここではshowアクションのテストを見てみます。

test "should get show" do
  get word_url(words(:tall))
  assert_response :success
  assert_select "nav a", {text: /変更|削除/, count: 2}
  assert_select "nav a.disabled", {text: /変更|削除/, count: 0}

  id = words(:tall).id+words(:house).id
  get word_url(id)
  assert_response :success
  assert_select "nav a.disabled", {text: /変更|削除/, count: 2}
  assert_equal "データベースにはid=#{id}のデータは登録されていません", flash.now[:alert]
end

フィクスチャのtallをパラメータにしてGETアクセスし、showアクションにルーティングさせます。 レスポンスは正常になるはずですので、assert_responseでチェックします。 その場合「変更」と「削除」メニューが「disabledでなく」表示されるので、2つのassert_selectでテストします。

• まず、ナビゲーションバーに「変更」または「削除」へのリンク（aタグ）が2個あることをテスト
• 次に、その「変更」または「削除」へのリンクでdisabledのものは0個であることをテスト

次に「データベースに存在しないid」でshowアクションにアクセスした場合をチェックします。 初期状態ではtallとhouseのフィクスチャのみがデータベースにあるので、それらのidの和であれば、データベースにそのidは存在しないはずです。 そのidをパラメータにしてアクセスすると、レスポンスはsuccessですが、データは表示されません。 また、ナビゲーションバーの「変更」と「削除」リンクはdisabledになっています。 assert_selectでそれをチェックします。 また、フラッシュが表示されるはずなので、assert_equalでフラッシュの内容をチェックします。

今回はshowメソッドのみで「変更」「削除」のenabled/disabledのチェックをしましたが、他のアクションでは常にdisabledのはずなので、それをテストに加えるのも良いと思います。

ビューのテストはあまりしつこくやっても意味は無いのですが、このように画面によってdisabledになるようなリンクをテストするのは有意義です。

結合テスト

結合テストでは複数のアクションがアクセスの流れの中で正しく呼び出されるかをテストします。 機能テストとの違いは、ひとつのアクションのテストか、複数かの違いになります。

まず、雛形を作ります。

$ ./bin/rails generate integration_test word_flows
      invoke  test_unit
      create    test/integration/word_flows_test.rb

/test/integration/word_flows_test.rbにテストを記述します。 ここでは3つの流れについてテストをします。

• 単語を作成： new ⇒ create ⇒ show
• 単語を変更： edit ⇒ update ⇒ show
• 単語を削除： delete ⇒ index

結合テストではリダイレクトのレスポンスが送られたときに、そのリダイレクト先にアクセスするfollow_redirect!メソッドを使います。

require "test_helper"

class WordFlowsTest < ActionDispatch::IntegrationTest
  test "flow from new to show through create" do
    # access to the new action
    get new_word_url
    assert_response :success
    # access to the create action
    post words_url, params: { word: { en: "stop", jp: "止まる", note: "" } }
    assert_response :redirect
    follow_redirect!
    # redirect to the show action
    assert_response :success
    assert_equal "単語を保存しました", flash[:success]
    assert_select "ul.list-group" do
      assert_select "li", "stop"
      assert_select "li", "止まる"
      assert_select "li", ""
    end
  end

  test "flow from edit to show through update" do
    # access to the edit action
    word = words(:tall)
    get edit_word_url(word)
    assert_response :success
    # access to the update action
    patch word_url(word), params: { word: { en: "tall", jp: "背の高い", note: "How tall is she?\n彼女はどのくらい背がありますか？" } }
    assert_response :redirect
    follow_redirect!
    # redirect to the show action
    assert_response :success
    assert_select "ul.list-group" do
      assert_select "li", "tall"
      assert_select "li", "背の高い"
      assert_select "li", "How tall is she?\n彼女はどのくらい背がありますか？"
    end
  end

  test "flow from delete to index" do
    # access to the delete action
    word = words(:house)
    delete word_url(word)
    assert_response :redirect
    follow_redirect!
    # redirect to the index action
    assert_response :success
    assert_select "h1", "単語帳"
  end
end

最初のテストだけ説明すれば十分だと思います。 2番めと3番めについてはソースコードを追ってみてください。

最初のテスト部分を再掲します。

test "flow from new to show through create" do
  # access to the new action
  get new_word_url
  assert_response :success
  # access to the create action
  post words_url, params: { word: { en: "stop", jp: "止まる", note: "" } }
  assert_response :redirect
  follow_redirect!
  # redirect to the show action
  assert_response :success
  assert_equal "単語を保存しました", flash[:success]
  assert_select "ul.list-group" do
    assert_select "li", "stop"
    assert_select "li", "止まる"
    assert_select "li", ""
  end
end

• getメソッドを使い、newアクションにアクセスする
• 応答はsuccess。入力フォームが表示されるがそのチェックは省略
• 単語stopをパラメータにセットしてpostメソッドでcreateアクションにアクセス
• 応答はredirect
• follow_redirect!メソッドでリダイレクト先（showアクションになるはず）にアクセスする
• 応答はsuccess
• 「単語を保存しました」のフラッシュが表示されるはずなのでassert_equalでチェック
• 保存された単語が順序なしリストで表示されるはずなので、それをチェック。 まず、assert_selectでul.list-groupセレクタをキャッチする。 そのブロックでは、キャッチされたセレクタ内のみを対象としてassert_selectが働く。 リストの項目として「stop」「止まる」「」（空文字列）があるはずなのでチェック。 なお、assert_selectの第2引数が文字列のときは、そのセレクタ（HTMLタグ）で囲まれたコンテンツの文字列との一致をチェックする

このようにして、複数のアクションにまたがるフローをチェックできます。

結合テストではクライアントのリクエストをシミュレートしてそれに対する応答をチェックしました。 しかし、現実にはブラウザで表示された画面の中でボタンやリンクのクリックなどが行われます。 そこまでのシミュレートは結合テストではできません。 そのチェックはシステムテストならば可能です。 次回はシステムテストについての記事を掲載する予定です。

• 2023 8
• 2022 37