WEB+DB PRESS vol.61 Rails3テスト最前線がすばらしい

ruby ruby on rails mac

WEB+DB PRESS vol.61の「Rails3テスト最前線」という記事がかなり良かったので、注釈を交えて紹介したいと思います。

何が良かったのか？

自分はRails2系でTest::Unitを実践していました。AutoTestとYAMLによるデータ投入でおおむね満足していましたが、次のポイントが気になっていました。

  • YAMLによるデータ投入は重複が多いのでコピペでデータを作成していた。
  • Test::Unitはログイン処理など共通の処理をくくり出すのが難しかった。
  • Viewのテストの方法が分からなかった。

しかしこの記事で気になる点がスパッと解消されました。私と同じような人はこの雑誌の記事が役に立つと思います。
ちなみに私はMacのSnow Leopard上でRuby1.9.2を使ってこの記事の内容を試しました。1.8.7を使う前提で書かれている箇所もあるので注意してください。（後で説明します。）

第1章

テストの種類と使用するツールの説明です。同じ目的のツールでもメリット・デメリットが書かれていてどのツールを選択すれば良いのかがよく分かりました。

第2章

RSpecを使用して実際にテストを書いていきます。モデル・ビュー・コントローラー・ヘルパーと進んでいくのですがちゃんとTDDが実践されており、アプリがだんだんと作成されていくのが実感できます。テストがちゃんと書かれたアプリはちょっとやそっとの改変で退行バグを生み出したりはしません。強固なシステムが出来上がっていくのを体験するのはとても楽しいです。
気になったこと
p.62の

$ rake db:migrate

の後に

$ rake db:test:clone

を行わないとテスト用DBが作成されません。

第3章

シンプルで分かりやすいテストの書き方と、factory_girlというFixture Replacementライブラリの使い方が書かれています。factory_girlはかなり気に入りました。Unitテストで正常系と異常系のテストを行うことを考えてみてください。YAMLだとそれぞれを別に書く必要があるのですが、factory_girlを使うとオリジナルから少しだけ改変したデータを作り出すことができます。

第4章

実際にWebブラウザ経由でアプリケーションを使うことを想定したテストである「エンドツーエンドテスト」の解説です。
Capybaraを使えば簡単にブラウザからの操作を記述することができます。
気になったこと
MacでCapybaraをインストールしようとするとエラーが発生しました。関連するnokogiriというgemがコンパイルできないようです。portsでlibxml2を事前にインストールしておきましょう。

sudo port install libxml2

あとp.78のnew_article_spec.rbを実行するコマンドはdocumentじゃなくてdocumentationが正しいかも。

$ rspec --format documentation spec/requests/new_article_spec.rb

また、Ruby1.9系はenvjsをインストールすることができないようです。私は記事で紹介されていたakephalosを使用してJavaScriptのテストを書いてみました。akephalosを使用する際はspec/spec_helper.rbに次の行を追加してください。

require 'akephalos'
Capybara.default_driver = :akephalos

Capybara.javascript_driverじゃないので注意！あと、記事にも書かれていますがdefault_driverをakephalosにとっかえちゃうとエンドツーエンドテスト全てが遅くなります。p.81に書かれている「RSpecのフィルタ機能で切り替える方法」で必要なときだけakephalosを使うのが良いと思います。(githubにakephalosを使うときの例を公開しています)

第5章

自動実行や並列実行、ロード時間短縮等のテストを支えるツール群の話です。私はAutoTestをずっと使っていて、Growlとの連携スクリプトを書いたりしてそれなりに楽しく使ってたんですが、この記事でguard-rspecを知ってから移行することに決めました。標準でGrowlの連携ができるのもポイントが高いですし、「Guardfile」という監視フォルダの設定ファイルをいじることで監視対象を追加できるのもいいですね。

まとめ

Railsは短時間でサクサク動くものを作成することができます。なので完成したらすぐに上司に報告に行くのではなく、余った時間でテストコードを書くのが良いと思います。もちろん初めからTDDが実践できればなおのこと良いですね。テストコードを書くことでアプリケーションが固く、強くなっていくのを実感するのは楽しいです。あと、JavaやC#プログラマから「LLって実行するまでエラーがチェックされないから業務じゃ使えないよね？」と言われても「そういう単純なミスはテストコードで判明しますから」って切り返すことができますw
Webに点在する情報が一つにまとまっていて、現時点で最高のRailsテスト解説だと思うので全てのRailsプログラマにお勧めします。
WEB+DB PRESS Vol.61
WEB+DB PRESS Vol.61