kanazawa.js v1.7に行ってきた

[2012-04-09 追記]

いつも思うが kanazawa.js はサポートスタッフがすげぇ。

2ヶ月。これで頭がいっぱいでした。ぶっちゃけ。

スライドのレビューを受けてくれた皆さん、ありがとうございました。最後は頭領に一刀両断にされてしまいました（笑うとこね）が、その甲斐もあってなんとか時間内に必要なことは喋り終わり、質疑にも応じることができました。

事後報告でスライドの引用を了承していただいた和田さんには、実は資料からは削除したスライド中で登壇してもらったりしています。重ね重ねありがとうございます。（引用元明示してないんだけど…）

前日までの段取りや会場の準備や受付をしていただいたスタッフの皆さんありがとうございました。

久しぶりの発表で出だしはイマイチでしたが、なんとか笑いも拾うことができ、Togetterを見る限りは何人かには興味を持ってもらえ、懇親会でも何人かから突っ込んだ質問を受けることができました。ちゃんと伝わったんだなーとホッとしています。

推敲の段階でバッサリ捨てた資料を回収してリンクだけでも張ろうかなと思ってはいるんですが、とりあえず無事終わってよかったという気持ちだけ置いておきます。

あえての電波マシマシです。初めて外部のサービスにスライド置いたわ。

あとは注釈とか言い訳など。

  • スライド中のコードがモノクロなのは showoff + pdfkit の仕様みたいです。見づらくてごめんなさい。（発表のときはハイライトされてたんですが）
  • 回転と言えば「ろくろ」、だからWeb業界はテストと相性がいいです、というネタを完全にすっ飛ばしてました。
  • 懸命に削りましたが、詰め込みすぎてごめんなさい。

関連して最近考えていたことなどは別エントリに起こそうと思います。

自分のやり方

今のところ自分は jasmine gem で HTTP サーバ起こしてブラウザで開いて、guard-livereload でブラウザに自動的にリロードさせて回すことが多いです。Rubyist なので、Ruby でまとまってると楽ですね。

今後の課題とか

現実的に Web のフロントエンドの JavaScript で TDD をやろうとするときに必要となりそうなものを挙げていくと

  1. fixture ( DOM の準備 )
  2. stub, mock ( Test Double )
  3. Ajax, Timer の double と非同期テスト
  4. テスト実行の負荷軽減 ( guard-livereload など )
  5. テスト記述の負荷軽減 ( CoffeeScript )
  6. 分散バージョン管理システム ( Git, Mercurial など )

辺りでしょうか。これらを理解、実践できるようになると強いです。

テストについての知識

  • fixture ( DOM の準備 )
  • stub, mock ( Test Double )
  • Ajax, Timer の double と非同期テスト

辺りの話は、特に fixture は押さえてないと厳しいかなと思います。目視の負担や不確実性を少しでも排除したいなら必須と考えていいんじゃないでしょうか。

Ajax は恐らく今の Web では避けて通るのは難しく、そのために非同期のテストやリクエストのすげ替えができるとよいです。と言っても非同期で処理しなければテストできない部分は多くないので、ギリギリまで避けて通ることもできますけど。（ただ、往々にしてこのギリギリで避けた部分にミスが入り込むんですが）

テストの記述や実行環境の知識

  • テスト実行の負荷軽減 ( guard-livereload など )
  • テスト記述の負荷軽減 ( CoffeeScript )

ここら辺ができるととても楽に TDD のサイクルを回すことができるようになりますが、いずれにせよ KUROIGAMEN を完全に排除するのは難しいかなぁという印象があります。何か一つ、Ruby でも node.js でもなんでもいいから使えるものを用意できると強いです。まぁ我慢しようと思えばできなくもないですけど。使えないと TDD できないのかと言われれば、なくてもできます。

バージョン管理

もう一つ、決定的なものは

  • 分散バージョン管理システム ( Git, Mercurial など )

を使えるとよいです。とてもよいです。

というのも、小さく進めるたびに進捗を確実に記録できるので、これがまた安心に繋がります。一応 Green のテストを維持しながらリファクタリングすることで安心を確保できるのですが、リファクタリングの際にバッサリとコードを削れる（削っても元に戻せる）という安心感も大切ですし、特に分散バージョン管理システムは

  • 小さなステップ単位で他に影響しないツリー（branchなど）を作成できる
  • できあがってしまったらあとでこの小さなステップはまとめてしまえるので、後から読む人にとっても読みやすい記録にできる

など、TDD と相性がとてもよいのです。

ただ、セミナー形式ではここまでやろうとしても眠いだけなので、ハンズオンの機会があるといいかなぁという感じですね。それが kanazawa.js になるのか kanazawa.tdd みたいな何かになるのか、何も考えてないですけど。

そう言えば自分でも CoffeeScript を使ったテストの記述はやろうやろうと思いつつまだやってないですね。考えたら jasmine + guard なんだから spec/coffeescripts とか作ってそこからどんどん変換してやるだけですね。今度やってみよう。

リンクだけ抜き出したり足したりしてみます。もし興味があったら掘ってみてください。

関連リンク

スライド関係

TDDBC関係

関連エントリ

More