rubygems-test で rubygems インストール時にテストを行う

Ruby のパッケージングマネージャの rubygems と Perl の CPAN と比較して、rubygems の残念なところの一つに『インストール時にテストを行わない』ことが挙げられます。rubygems は gem install package で一発で入れられる事は便利なんですが、インストール時にテストが行われないため、実際にその環境で正しい挙動をするとは限りません。また、rubygems で入れたパッケージのテスト方法もコマンド一発で簡単にできるわけではないのでめんどくさかったりします。なにより問題なのが、インストール時にテストが行われないため『開発者がテストをさぼりがち』になってしまいます*1。
最近 rubygems でも CPAN と同じように、インストール時にテスト可能なパッケージはテストを行い、失敗したら基本的にインストールできない(設定で変えられます)仕組みを持ったライブラリ、rubygems-test が登場しました。

インストールは簡単で

gem install rubygems-test

して、~/.gemrc の設定に以下の感じで設定を追加します。(詳しくは https://github.com/rubygems/rubygems-test とか読んでください)

test_options:
  auto_test_on_install: true # package のインストール時に自動でテストを行うか
  test_on_install: true # package のインストール時にテストを行うか(Y/n)で尋ねられる
  install_development_dependencies: true # add_development_dependency なパッケージもインストールするか
  test_development_dependencies: false # add_development_dependency なパッケージもテストするか(たぶん)
  upload_results: false # テスト結果を test.rubygems.org にアップロードするか
  force_install: false # テストに失敗しても強制的にインストールするか
  force_uninstall_on_failure: false #  テストに失敗したらアンインストールするか(たぶん)

これで"テストの設定が適切にされている"ライブラリの場合、自動でテストが実行されます。"テストの設定が適切にされている"ライブラリというのは以下の条件を満たしてるライブラリです。

  • パッケージに .gemtest が含まれている
  • rake の test タスクがある

Jeweler などでパッケージのひな形を作ってる場合、Gemfile から勝手に依存ライブラリ周りの設定は生成されるので、.gemtest を作って git add して、rake spec なタスクしかなかったら、rake test なタスクで spec が実行される(ちょっと微妙ですが…)タスクを用意すればそれだけで終わりで簡単ですので、gem ライブラリの作者は用意すると良いと思います！
また、rubygems-test を入れると gem test package 名でテストを実行でき、結果のレポートを test.rubygems.org にアップロードすることもできます。

というわけで、最近は rubygems も徐々に CPAN に近づいてきた感があります。まだ rubygems-test プロジェクトは始まって4ヶ月ぐらいしかたっておらず、rubygems によりテスト文化を根付かせるためにも、是非みなさん使ってみましょう。特に gem の作者は是非 .gemtest を設置して、インストール時にテスト可能なパッケージを作っていきましょう :D

*1:CPAN ならテストが無かったりテストが適当なパッケージはクオリティが低いライブラリと認定しますよね

大江戸Ruby会議01 高速なテストサイクルを回すには

本日大江戸*1で行われた大江戸Ruby会議01で、高速なテストサイクルを回すにはという内容で発表してきました。

大江戸Ruby会議01 高速なテストサイクルを回すには
View more presentations from hotchpotch

テストを速くするには二パターンあり、一つは単体実行時の速度・フィードバックの高速化、もう一つはすべてのテスト実行時の高速化があると思っていて、それらについての話です。ぎゅっとまとめると、前半の単体実行時の速度・フィードバック高速化には spork / prefetch-rspec / autotest / watchr を使おうという話と、後半は REE / parallel_tests による高速化・並列実行、remote spec によるリモートマシンでの分散テストについての話です。
特にオレオレプロジェクトの prefetch-rspec と会社で運用してる remote spec の話*2が受けが良かったのが嬉しかったです。prefetch-rspec は是非使って叩いてパッチなりコントリビュート(もしくはgithub.com/asakusarb プロジェクトとしてリリース)してもらえたりするととても嬉しいですね :D

また、大江戸Ruby会議01 自体も面白くて刺激的だったので、スタッフの方々、スピーカの方々、参加者の方々、どうもありがとうございました！

*1:清澄白河

*2:ちなみに偉そうに話してましたが remote spec は僕が作ったんじゃなくて、同じ開発基盤チームの同僚のアイディアと実装です。すごく改善されて同僚に超感謝

さいきんの 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周りでテストを回す環境を整えると、とてもチーム開発がやりやすくなるので、その辺も視野に入れるとより楽しいテストライフが待ってると思います！