トップ 最新 追記

2012-02-09 [長年日記]

_ 実はCapybaraってよく分からないんです

というか、この辺の用語がいつも混乱してとても困っていたのでいったん整理。今回のターゲットは何やら最近 JavaScript を含む Web アプリのテストでよく名前を聞く

capybara-webkit

からスタート。

間違ってたら突っ込んでください! 間違ってなかったら褒めてください!

名前

capybara-webkit
Capybara の driver. Capybara のテストを WebKit を通じて実行できる。WebKit と言えばみんな大好き、Google Chrome や Safari のエンジンですね。
capybara
テスティングフレームワークに対して Web アプリのテストを書きやすくする語彙を提供してくれる( DSL や Driver で実装されている )。driver は default で rack_test で、JavaScript を含む場合は Selenium になる。*1
cucumber
語彙の定義をしてあれば日本語でもテストを記述できる BDD フレームワーク。主に受け入れテスト用として人気?

ここまで全部 Ruby 製。

links

ただし

Cucumber を PHP アプリに対して本当に使えることが分かった

に書いたように、アプリケーションは Ruby 製である必要はない。その場合は

jeroenvandijk/capybara-mechanize - GitHub

を使う。mechanize については今回は端折ります。

もう一度まとめると

  • capybara の default driver である rack_test は rack アプリしかテストできない
  • default の javascript_driver である selenium は remote server にアクセス可能
  • rack_test を capybara-mechanize に差しかえると non-JavaScript の部分も remote server へアクセス可能

みたい。ということは rack_test 使ってる間は本物の http request は飛ばないのか…。

ちなみに capybara は Web アクセスをシミュレートしてくれるので、これは外から Web アプリをテストするためのものですね*2。純粋に JavaScript のユニットテストを行う場合は QUnit, Jasmine, 最近だと Mocha なんかを使います。

ところでなんでCapybaraなんだろう

たぶんだけど提供してくれる API がステキなんじゃないかなぁという印象。Ruby でテストを書きたいだけなら他にも選択肢はあるし。Selenium じゃないのはブラウザ部分を取っ替えてより速く実行できるのがみんな好きみたい。

Capybaraってテスティングフレームワークですか?

違います。

Web のアクセスをシミュレートするヘルパーです。

だから実際のテストは Cucumber や RSpec なんかで書きます。

おまけ

Jasmine にも Web サーバ起こすだけのやつと Selenium 使うやつがあったけど、WebKit 使うやつはないのかなぁと思ったらこれが見つかった。

jasmine-headless-webkit -- The fastest way to run your Jasmine specs!

ブラウザ立ち上げっぱなしで guard-livereload で回してもいいけど、CLI で完結するのもステキ。何らかのサーバで動いているであろう CI に向いてますね。もちろん Selenium と違って起動も速いので普段使いにもオススメです。

これは今度試そう。

こんな感じか。

余談

レガシーなコードもたくさんあるのでそういうときにせめて外からテスト揃えておくと安心だよねぇと調べてから思ったけど、それって

Rails での spec:requests にも同じことが言えるんじゃ?

と思い始めた。今まで request を元に内部で分岐する部分のテスト以外は真面目に書いてなかったけど、

単にちゃんとページが返ってくる

ことを spec でガードしておくのも大事だなと急に思い直した。初期の頃にはほとんど意味を感じない spec だけど、ある程度複雑になってきたときに予想していなかったところに影響が出てしまったことを素早く検知するために、

「ページが表示されて当たり前じゃん」と思っていても spec:requests は書いておいた方がいい

んだな。たぶん。なるほど。なんか Model や Helper やらに意識がいきすぎてた。

参考

JavaScriptのテスト事情-ダイジェスト版- 2011年10月13日

あとで見つけたんだよ! ほんとだよ!

*1 yet another webrat の意味で capybara って名前になったんじゃないかなぁと思ってるんだけど真相は知らない。

*2 rack_test の場合は云々というのはとりあえず置いておく


2012-02-29 [長年日記]

_ gitのcommitをbranchにぶちまける

どういうことか

  • gitのcommitを後から順番にトレースしたい

と思ったのです。git の working tree の更新は checkout や reset などでできるわけですが、トレースとなるとつまりこれらのコマンドを何回も発行する必要があります。

また reset や checkout は基本的には HEAD が変わってしまうので以前の commit に戻すには reflog から掘り起こす必要があります。そうすると何回も commit を行ったり来たりするのは単に checkout や reset を何回も発行するだけでなく合間に reflog も叩きまくりになると思います。

たぶんですけど。

で、これは面倒だなぁどうしようかなーと思ったんだけど branch に一つ一つ checkout してしまうのがラクチンかなと思いついたわけです。

こんな感じ

やってることは

  1. git log --reverse --oneline で commit を取得
  2. hash だけ抜き出して
  3. 頭に数字の prefix 付けて hash を branch 名にして checkout しまくる

というものです。

上の gist は Ruby で書いていますが、printf というコマンドがあるのをすぐあとに知ったので、Ruby を使わなくても sh + awk + printf 程度で十分実現できます。

master で実行すれば master の履歴が branch に展開されますし、どこかの branch で実行すれば同様にその branch の履歴を追いやすくなります。

何に使うのか

例えば料理番組風ライブコーディングで、この ticket の実装後のコードがこれになります、みたいな説明をしやすいかなと考えています。

単に流れを追うだけなら tig などのリポジトリビュワーを使って diff を見ればいいのですが、そのときそのときの commmit の状態を再現して実行したい、といった場合には恐らく役に立ちません。

今回の方法がたぶんいちばん簡単だと思うのですが、もっといい方法があったら教えてください。

あ、作業中のリポジトリにいきなり branch を作りまくるので、コピーしてから使ってください。

Tags: Git