こんにちは。murahashi sanemat kenichi です。開発で重要なのはフィードバックのサイクルを素早く回すことですよね。
こうなってくれるとうれしい。
落ちるテストを保存するとred
通る実装を保存するとgreen
フィードバックサイクル
簡単に達成するために必要なのは次の4つです。
テストコードのグルーピング、ファイル更新検知、ファイル対応関係、screenのstatus line
Symfonyの場合の話を順にみていきます。
一発でグループ分けされたテストコードが走る仕組み
Symfonyは簡単
$ php symfony test:unit #=> 全ユニットテストが走る
$ php symfony test:all #=> 全テストが走る
$ php symfony test:functional NAME #=> NAMEの機能テストが走る
ファイル更新検知をして、それをトリガに別のスクリプトを呼び出す仕組み
Symfonyのアプリルートを watchr で監視して、レシピは symfony-watchr 書きました。
あるファイルを更新したときに、対応するテストがわかりやすい仕組み そしてその逆も
Symfonyは設定より規約 convention over configuration のルールに従っているので、対応するファイルがわかりやすいです。
テスト結果をparseして、GNU Screenのstatus lineに流し込む仕組み
autotest_screen から、screenのstatus lineに表示する部分をはがして screenout に切り出しました。
これで楽しいdeveloper testing lifeがおくれるようになりました。
$ watchr ~/work/symfony_watchr/bin/symfony_watchr.rb
screenoutとwatchrとsymfony_watchr組み合わせた時の欠点
欠点1
ファイルの対応関係を雑に書いたので、粒度が大きすぎて素早いフィードバックが回らなかった。
- modelかunit以下のファイルを更新したら全unit testが走る
- test/functional 以下のファイルを更新したら、そのfunctional testが走る
欠点2
コードが悪くて、会社環境だと100MB近くメモリ食ってた
そしてどこがわるいかよくわからない
車輪の再発明感満載なので、どなたか、もっとまともな組み合わせがあれば教えてください。
cpan探したのですがどこみていいかよくわからなくて、みんなどんなの使ってるんでしょう。
というわけで、 rspec と autotest と autotest_screen の説明をお送りしました。
参考URL
- autotest で Symfony + Lime を自動テストする -- ディノオープンラボラトリ
- screenでない場合、Stagehand_TestRunnerでなんとかなるんじゃないでしょうか。
- rubyでtmuxの人に autotest-tmux
- growlは自分で探して
Symfony Advent 2010
Symfony Advent 2010 では12月1日から12月24日までを使って日替わりで symfony でイイなと思った小さな tips から内部構造まで迫った解説などを ブログ記事にして公開していくイベントです。
※Syfony Advent 2010はsymfony好きな有志で集まったチームです。
以上デース