RSpecとCapybaraでJavaScript/Ajaxをテストする

RSpecはRubyのためのビヘイビア駆動開発(BDD)フレームワークで、Capybaraはブラウザの動きをシミュレートするRubyライブラリで、どちらもRubyGemsパッケージとして配布されています。Railsアプリケーションのテストを書く場合の定番の組み合わせといっていいでしょう。

たとえば、ユーザーがあるRailsアプリケーションのトップページにアクセスして、a#touchmeをクリックしたら、次のページのp#messageに「Hello!」というテキストが含まれることをテストしたい場合、次のようなSpecファイルを書きます。

# coding: utf-8

require 'spec_helper'

describe "Topページ" do
  before { visit root_path }
  
  context "a#touchmeをクリックすると" do
    before { find("a#touchme").click }

    specify do
      within('p#message') do
        expect(page).to have_content("Hello!")
      end
    end
  end
end

さて、このRailsアプリケーションがJavaScript/Ajaxを利用していて、「span#touchmeをクリックしたら、p#messageの中に動的に「Hello!」というテキストが現れる」という仕様であった場合は、どうテストすればよいでしょうか。単にa#touchmeをspan#touchmeに変えるだけではだめです。CapybaraはJavaScriptを理解しないので、テストは失敗します。

ここで登場するのがcapybara-webkitというドライバです。WebKitはオープンソースのHTMLレンダリングエンジンで、Google ChromeやSafariがこれを使っています。このドライバを使えばJavaScriptのテストが可能になります。

capybara-webkitをインストールするには、例によってGemfileに

  gem "capybara-webkit"

と書いて、bundle installを実行します。ただし、システムにQtのライブラリがインストールされていないと動きません。Mac OS X (Mountain Lion/Lion)の場合は、brew install qtでインストールします。Ubuntuの場合なら、libqt4-devパッケージをapt-getで入れておく必要があります。

もう一つ準備作業が必要です。spec/spec_helper.rb の末尾に次の1行を追加してください。

Capybara.javascript_driver = :webkit

CapybaraはデフォルトでWebKitを使いません。describeやcontextメソッドにjs: trueオプションを付けると、その範囲のエグザンプル（RSpec用語では「テストケース」をこう言います）だけWebKitによるテストを行います。書き換え後のSpecファイルは次のようになります。

# coding: utf-8

require 'spec_helper'

describe "Topページ" do
  before { visit root_path }
  
  context "span#touchmeをクリックすると", js: true do
    before { find("span#touchme").click }

    specify do
      within('#message') do
        expect(page).to have_content("Hello!")
      end
    end
  end
end

これでテストが通るようになります。

さて、単純なテストはこれでいいのですが、データベースが絡むと少々ややこしい問題に遭遇します。実は、WebKitを使用する場合、Capybaraは別スレッドでRailsアプリケーションを起動します。そのためRSpec側とRailsアプリケーション側は別々のデータベース接続を持つことになります。

通常、RSpecは各エグザンプルの終わりにデータベースの状態を素早く元に戻すため、エグザンプルをトランザクションの中で実行します。エグザンプルが終わったらロールバックするんですね。トランザクションの中で行われたデータベース操作の結果は、コミットされるまで他のデータベースクライアントには見えません。RSpecの中でデータベースにレコードを追加しても、それがRailsアプリケーションには分からないのです。

この問題への伝統的な対処法は、JavaScriptを使ったRailsアプリケーションをCapybaraでテストする際には、spec/spec_helper.rbの

  config.use_transactional_fixtures = true

をfalseに変え、config.after(:each) ブロックの中でデータベースを空にするというものです。そのための専用のRubyGemsパッケージdatabase_cleanerも存在しています。確かにこれでテストは通るようになりますが、トランザクションのロールバックを利用するよりもかなり遅いのが難点でした。

しかし、昨年(2011年)の12月にRailsコミッタの一人José Valimがブログ記事 Three tips to improve the performance of your test suite の中で素敵なハックを紹介したことで状況が変わりました。

この記事を参考に私が試してみたところ、以下の手順を踏めば、config.use_transactional_fixtures = true のままでJavaScriptのテストができます。

まず、spec/supportディレクトリに、次のような内容を持つ新規ファイルshared_connection.rbを作成します。

class ActiveRecord::Base
  mattr_accessor :shared_connection
  @@shared_connection = nil
 
  def self.connection
    @@shared_connection || retrieve_connection
  end
end

そして、spec/spec_helper.rb の末尾に次の1行を追加します。

ActiveRecord::Base.shared_connection = ActiveRecord::Base.connection

このハックはSporkにも対応しています。Sporkはテスト対象のアプリケーションを読み込んでおいて、テストケース（エグザンプル）ごとにforkしてくれます。その結果、テストがより堅牢になり、たいていは時間も短縮されます。

Sporkの使い方は本稿のテーマではありませんが、簡単に説明します。例によってGemfileに

  gem "spork"

と書いて、bundle installを実行します。続いて、spork rspec --bootstrap を実行すると、spec/spec_helper.rb が書き換えられます。

require 'rubygems'
require 'spork'
#uncomment the following line to use spork with the debugger
#require 'spork/ext/ruby-debug'

Spork.prefork do
  # Loading more in this block will cause your tests to run faster. However,
  # if you change any configuration or code from libraries loaded here, you'll
  # need to restart spork for it take effect.

end

Spork.each_run do
  # This code will be run each time you run your specs.

end

# --- Instructions ---
(以下省略)

簡単に言えば、SporkはSpork.preforkブロックに書いてあるコードを1回だけ実行し、Spork.each_runブロックに書いてあるコードをエグザンプルを実行する直前に毎回実行します。

基本的には、# --- Instructions ---よりも下にあるコード（もともとのspec_helper.rbの中身）を全てSpork.preforkブロックに移動すればOKです。

ただし、José Valimのハックで追加した

ActiveRecord::Base.shared_connection = ActiveRecord::Base.connection

は、Spork.each_runブロックに移す必要があります。

rspecを実行するのとは別のターミナルを開いて、そこでsporkコマンドを実行するとテストサーバが起動します。そして--drbオプションを付けてrspecコマンドを実行すると、Spork経由でテストが実行されます。

Sporkによる時間短縮の効果はけっこう大きいです。ちょっとしたサンプルを作って試してみたところ、全体で約6秒かかっていたテストが約3秒になりました。