Rails tips: RSpecテストの高速化/リファクタリングに役立つ4つの手法（翻訳）

概要

原著者の許諾を得て翻訳・公開いたします。

• 英語記事: Speed up and refactor your RSpec tests in 4 simple steps
• 原文公開日: 2018/03/25
• 著者: Paweł Dąbrowsk

Rails tips: RSpecテストの高速化/リファクタリングに役立つ4つの手法（翻訳）

どんなアプリであってもテストは非常に重要な部分ですし、テストをきれいに書くこともやはり重要です。しかしテストスイートを高速かつきれいに保つのが困難になることがあります。特に自分より前に（あるいは現在）複数の開発者が寄ってたかって作った案件でそうなりがちです。本記事では、主に2つの面でテストを改善することに注力します。テストで繰り返し出現している共通部分のリファクタリングと、データベースリクエスト削減によるテストの高速化です。準備はよろしいでしょうか？

1. shared_examples

次の例で考えてみましょう。

class AgePolicy
  def old_enough?(age)
    age >= 18
  end
end

このシンプルなポリシーは、指定のユーザーがアプリでしかるべき操作を行ってよい年齢になっているかどうかをチェックします。このクラスのごく簡単なテストがあります。

require 'spec_helper'

describe AgePolicy do
  describe '#old_enough?' do
    it 'ユーザーが16歳ならfalseを返す' do
      policy = AgePolicy.new

      expect(policy.old_enough?(16)).to eq(false)
    end

    it 'ユーザーが12歳ならfalseを返す' do
      policy = AgePolicy.new

      expect(policy.old_enough?(12)).to eq(false)
    end

    it 'ユーザーが18歳ならtrueを返す' do
      policy = AgePolicy.new

      expect(policy.old_enough?(18)).to eq(true)
    end

    it 'ユーザーが20歳ならtrueを返す' do
      policy = AgePolicy.new

      expect(policy.old_enough?(20)).to eq(true)
    end
  end
end

ご覧のとおり、テストで変動している部分は年齢しかありません。こんなときは、RSpecテストフレームワークのshared_examples機能が使えます。

require 'spec_helper'

describe AgePolicy do
  describe '#old_enough?' do
    shared_examples '操作を行ってよい年齢のユーザー' do |age|
      it "ユーザーが#{age}歳ならtrueを返す" do
        policy = AgePolicy.new

        expect(policy.old_enough?(age)).to eq(true)
      end
    end

    shared_examples '操作を行えない年齢のユーザー' do |age|
      it "ユーザーが#{age}歳ならfalseを返す" do
        policy = AgePolicy.new

        expect(policy.old_enough?(age)).to eq(false)
      end
    end

    it_behaves_like '操作を行えない年齢のユーザー', 16
    it_behaves_like '操作を行えない年齢のユーザー', 12
    it_behaves_like '操作を行ってよい年齢のユーザー', 18
    it_behaves_like '操作を行ってよい年齢のユーザー', 20
  end
end

これでテストは少し速くなりましたが、まだ終わりではありません。テストは少しばかり読みにくくなったものの、同じコードをexampleごとに繰り返さなくなりました。

2. カスタムマッチャー

RSpecにはさまざまな便利マッチャーがあります。上の例で既にbe_truthyやbe_falseyを使いました。指定の値を期待するのに同じコードを何度も何度も繰り返していることがあります。コントローラでレスポンスをテストする場合が手頃なサンプルだと思います。次の例を考えてみましょう。

class SomeController
  def show
    render json: { success: true }
  end
end

レスポンスのsuccess属性がtrueになるかどうかをどのようにテストすればよいでしょうか？次のようにします。

describe SomeController do
  describe 'GET #show' do
    it 'successレスポンスを返す' do
      get :show, id: 11, format: :json

      expect(JSON.parse(response.body)).to eq({success: true})
    end
  end
end

上のテストを以下のように書ければこんな簡単な話はありません。

expect(response).to be_json_success

この行を見ただけではマッチャーが何をしているのかよくわかりませんが、アプリ全体に一貫したロジックがあるなら、このようなマッチャーを自作すれば挙動はおのずと分かるでしょう。こういうマッチャーを作成するには、spec/supportディレクトリの下にmatchers.rbファイルを作成し、次のようにマッチャーの定義をそこに書かなければなりません（ファイル名は何でも構いません）。

RSpec::Matchers.define :be_json_success do |expected|
  match do |actual|
    json_response = JSON.parse(actual.body)
    expect(json_response['success']).to eq(true)
  end
end

最後にspec_helper.rbファイルにrequire 'support/matchers'を記述してマッチャーをrequireすれば完了です。

3. ファクトリーから不要な関連付けを取り除く

このメソッドは、アプリでFactoryBot gemを使ってデータベース内の実際のレコードを扱っている場合に便利です。たとえばUserモデルがあり、各ユーザーは1つのContactレコードと1つのLocationレコードを持っているとします。このときのファクトリーは次のようになるでしょう。

FactoryBot.define do
  factory :user do
    contact
    location
  end
end

FactoryBot.create :userやFactoryBot.build :userを使うたびに、追加のレコードが2つ作成されます。もちろんbuildでもです。関連付けられたレコードを作成したくない場合は、代わりにFactoryBot.build_stubbed :userを使うことをおすすめします。

たとえばテスト全体で使われる基本のファクトリーがあるとします。2つの関連付けが常にデータベースで必要なら構いませんが、そうでなければテストのパフォーマンスを一気に向上させるチャンスです。基本のファクトリーが常にこれらの属性を持たなければならないのは、バリデーションにパスする必要がある場合に限られます。関連付けがときどき必要になるのであれば、traitsの利用をご検討ください。

FactoryBot.define do
  factory :user do
    first_name { "John" }
    last_name { "Doe" }

    trait :with_location do
      location
    end
  end
end

後はFactoryBot.create :user, :with_locationでファクトリーを呼べばよいのです。

4. Railsのトランザクションテスト機能を活用する

データベースの1レコードだけあればよいという状況は、テスト全体でどのぐらい占めていますか？先のuserファクトリーで簡単なテストを書いてみましょう。

require 'spec_helper'

describe User do
  let!(:user) { FactoryBot.create :user }

  it '何かする' do
    # userのテスト
  end

  it '何かする' do
    # userのテスト
  end

  it '何かする' do
    # userのテスト
  end
end

上のテストではUserのレコードがいくつ作成されるでしょうか。exampleごとに1回なので答えは合計3回です。test-prof gemの素晴らしい機能であるlet_it_beを使えばこれを回避できます。このヘルパーはRailsのトランザクションテスト機能を利用してレコードを最初に1回だけ作成し、テストが終了したら削除します。gemをインストールしたら、spec_helper.rbにrequire 'test_prof/recipes/rspec/let_it_be'と記述すればこのヘルパーを使えるようになります。

require 'spec_helper'

describe User do
  let_it_be(:user) { FactoryBot.create :user }

  it '何かする' do
    # userのテスト
  end

  it '何かする' do
    # userのテスト
  end

  it '何かする' do
    # userのテスト
  end
end

以上でおしまいです。同じレコードを使うexampleが多数ある場合は、specが50%高速化することもあります。データベースのレコードが不要な場合は常にスタブで塞いでおく方法もあります。

関連記事

Rails tips: RSpecテストを遅くする悪い書き方3種（翻訳）

Rails tips: RSpecのテスト設計でよくあるやらかし4種（翻訳）

Rails: テストのリファクタリングでアプリ設計を改良する（翻訳）