さいきんの JavaScript テスト / Test.js - Shibuya.js 発表資料

本日行われた Shibuya.js の発表資料をアップしました。

さいきんの JavaScript テスト / Test.js - Shibuya.js 発表資料
View more presentations from hotchpotch

JS のテスティングフレームワークのおおざっぱな説明や JavaScript テストにおける問題、それについての解決方法の一つ、CUI でのテスト、Envjs、エンドツーエンドテストにおける JS / Ajax のテスト、終わりにちらっと Phantomjs の話があります。
スライドの最後にあるように、やはりまだコレだ！という JS のテスティングフレームワークは存在しなく、今後 JS のテストは『僕らが書きたいテスト』をどれだけ簡単に書ける・書く手法が確立されるかによって流行廃りは決まってくるんじゃないかなぁ、と思ってます。そのうちの一つがスライド内にある Capybara + envjs(もしくはその他のブライザドライバ)の組み合わせがかなり Web アプリのテストにおける JS のエンドツーエンドテストの書きやすさという点ではオススメできるので、Rack アプリを使った開発をしている人は試してみる価値はあると思います。
また、本当にテストはCI等で自動化してテストを自動実行するところが最近重要だとひしひしと感じてるので、JS でテストを書くのに挑戦してる人は、きちんとCI周りでテストを回す環境を整えると、とてもチーム開発がやりやすくなるので、その辺も視野に入れるとより楽しいテストライフが待ってると思います！

watchr - ファイルに変更があったら何かする / もしくはオサーンについて

みなさま、いかがお過ごしでしょうか。以前人のことをオサーンオサーン云いまくっていたけどその当時のオサーン年齢のもうすぐ三十路になります secondlife ですこんばんわ。言葉のしっぺ返しが痛い今日この頃です。

さて、若かりし頃には合わなかったけど今使ってみるとしっくり来る物もありますね。その一つが AutoTest(ZenTest) です。ファイルが更新したらこける / SyntaxError になると解っていてもテストが走りFFF、自分のテストサイクルでテストが実行できないのが我慢できませんでしたが、久しぶりに使ってみるとそんなのは気にならず、いちいちテスト実行しなくてよくなってとても気持ちがよい感じです。

しかしながら ZenTest に含まれる AutoTest はレールが敷かれているテスト環境では利用しやすいけど、ちょっと道を踏み外すと結構テストを実行するのがめんどくさいです。そんなとき、海外では結構使われているのが watchr というライブラリ。最近のライブラリのカレントディレクトリに spec.watchr のようなファイルをちらほら見かけますが日本じゃ全く使われている気配がないので紹介します。

"flexible alternative to Autotest" との通り、AutoTest の代替としてももちろん使えますが、ファイルに変更があったら何かアクションをおこすという設定をさくっと書くことができます。

サンプルを見れば一目瞭然なんですが、

watch( 'test/test_.*\.rb' )  {|md| system("ruby #{md[0]}") }
watch( 'lib/(.*)\.rb' )      {|md| system("ruby test/test_#{md[1]}.rb") }

なかんじで watch() にマッチしたらアクション起こすコード書くだけです。それらを記述したファイルを name.watchr とカレントディレクトリに配置して watchr コマンドを叩くだけで簡単にファイル監視 -> アクションを行う事ができます。

もちろん Ruby のコードで色々できるので、たとえば css に変更があったら MozRepl 経由で Firefox をリロードなんかは

@telnet = nil
def browser_reload
  require 'net/telnet'
  @telnet ||= Net::Telnet.new({
    "Host" => "localhost",
    "Port" => 4242
  })
  # 見ているホスト名が localhost... ならリロード
  @telnet.puts("if (content.location.host.indexOf('localhost') == 0) content.location.reload(true)\n")
end

watch('^.*\.css') { browser_reload }

みたいにサクッと書くことができます。
また RSpec2 には特定の spec だけを実行する filter をよしなに記述することができるんですが、それができない RSpec1 で、特定の spec だけ実行したい場合、実行したい spec コードに # focus! とコメントしておくとそこの spec のみが実行されるようなコードはこんな感じに書けます。

def run(files_to_run)
  system("clear")
  file = Pathname.new(files_to_run)
  options = ''
  if file.exist?
    file.open.read.split("\n").each_with_index {|line, i|
      if line['# focus!']
        options <<  "-l #{i} "
      end
    }
  end
  puts("Running: #{options} #{files_to_run}")
  system("spec #{options} #{files_to_run}")
  no_int_for_you
end

watch('^spec/(.*)_spec\.rb') { |m| run_spec_matching(m[1]) }
...

アイデア次第で色々できそうな感じが良いですね。なお rspec + rails の組み合わせで使うには

とかを参考にすると良さそうです。

というわけで、みなさんも三十路に近づいてきたら、再度 AutoTest 系の自動テストを試してみるのも良いのでは無いでしょうか。なお三十路になる直前は、『まだ20代ですよ』と云うと三十路になった時ショックが大きいので、『もうじき三十路なんですよ』と云っておいた方がよいですよとありがたい忠告を、検索無料ですの会社の @ku さんからいただきました。ありがとうございます…。

プログラマが知る97のきのことに寄稿しました・クックパッドに入社(してま)した

12/18 にオライリーから発売される、97きのこ本ことプログラマが知る97のきのことに、"快適な環境を追求する" というエッセイを一本寄稿しました。みなさん、良かったら手に取ってみてください。

プログラマが知るべき97のこと

プログラマが知るべき97のこと

あ、今更間漂う報告ですが、2010年8月からクックパッド株式会社で働いてます。なんか報告のタイミングがずれていまさら感が漂いますが…。

クックパッドでは "快適な環境を追求する" ということで開発基盤チームに所属してます。開発基盤チームでは全員が利用するライブラリの開発から、サービスをより良くするにはどういった(ソフトウェア・プロセス両方の)フレームワークを用意すればいいのか考え実装したり、エンジニアが開発するに当たってコードの品質を維持し、すばやくリリースを行える仕組みは何が最適なのかを考え仕組みを作ったり、などなどを行ってます。

[PR] クックパッドではエンジニアを絶賛募集中です

絶賛募集中らしいので、興味のある人は話を聞いてみたり募集してみたりすると良いと思います！べつに Ruby できなくても大丈夫なので、人が喜ぶサービスを作りたい、クックパッドで挑戦してみたいことがある人は是非。