Wercker良いですよね。
無制限に、無料でプライベートリポジトリをビルド＋デプロイって、β版が終わった後の扱いが不安になるほどです。
(Werckerは、自動でテスト＋デプロイができるウェブサービスです)
http://wercker.com/
さて、テスト駆動も佳境になってくると、JSが必要となるテストを書かざるをえないと思います。ヘッドレスなPhantomJSなども良いですが、所感では、Seleniumの安心感はすごくあります。
ブラウザ互換でのテストも容易ですし。
なによりCIにおいては、デプロイ前のビルドを自動化することで、多少の時間は許容できるのがメリットではないでしょうか。そこで、
ここではWerckerにて、RSpec/Capybara/Selenium環境下でのテストを紹介します。
Wercker自体の使い方は下に詳しいので、ここでは直接 Seleniumが関係する部分のみ記述します。
Wercker自体の使い方
http://blog.mah-lab.com/2014/01/08/rails-wercker-heroku-deploy/
WerckerでSeleniumを使う
build:
steps:
- script:
name: Enable virtual display(thanks to zephiransas blog!
code: |
export DISPLAY=:99.0
start-stop-daemon --start --quiet --pidfile /tmp/xvfb_99.pid --make-pidfile --background --exec /usr/bin/Xvfb -- :99 -screen 0 1024x768x24 -ac +extension GLX +render -noreset
sleep 3
- desmondmorris/selenium-install@0.0.2
- script:
code: |
bundle exec rspec
部分解説その1
> export DISPLAY=:99.0
> start-stop-daemon --start --quiet --pidfile /tmp/xvfb_99.pid --make-pidfile --background --exec /usr/bin/Xvfb -- :99 -screen 0 1024x768x24 -ac +extension GLX +render -noreset
> sleep 3
上記パートは、下記 Wercker公式ブログでも紹介されています。
http://blog.wercker.com/2013/11/28/django-selenium.html
Werckerがビルド時に立ち上げる Linux環境化で、Seleniumが使うブラウザを立ち上げるためには、ヴァーチャルスクリーンを立ち上げておかなければいけません。上記がそのスクリプトです。
-
部分解説その2
- desmondmorris/selenium-install@0.0.2
上記は、Werckerの醍醐味でもある 第三者が作成、公開したスクリプト/仮想環境を使用するという宣言です。
https://app.wercker.com/#explore/steps/search/
にて、現在公開されているスクリプト（Wercker上では STEPと呼ぶようです）を一覧できます。
実際に上記のSTEPを見に行くと、seleniumのスタンドアロンサーバをダウンロードし、
キャッシュディレクトリ上で 起動していることが分かります。
https://github.com/desmondmorris/wercker-step-selenium-install/blob/master/run.sh
注意
自分たちのケースでは、テストがたまに失敗したり、かと思ったらさっきまで通っていたテストが Werckerのビルドでのみ失敗したりすることが起きました。これは、Seleniumが外部(s3)に置かれたファイルを呼びにいき、その応答時間次第で結果が変わる、という状態だったからです。
現在は sleep 3 など読まれるまで十分な時間を待つという応急処置で対処していますが、実際には VCR gem などを使って、外部との通信は 固定化した方がよいかと思います。
https://github.com/vcr/vcr
http://morizyun.github.io/blog/webmock-vcr-gem-rails/
それでは、ハッピーTDDライフを！