TDD Boot Camp in Tokyo 1.5 #tddbc に参加してきました
まとめリンクなど
感想まとめ
- すべての参加者の方が楽しめているようでした
- コードレビューという枠で他の人の設計を知ることができるのはよいものでした
- 個人的な想いなので運営、開催をされてる方々を非難するものではありませんが次の点は必要だったと思いました
- 課題とは別に、TDD という型を最初に示すべき
- TDD によって設計をどう進めたか、また、どう変わっていったのか振り返る時間は必要
- 各ワークショップごとの代表的な例でもいいのでコードを集積、その設計に至った知識の共有をする時間を持つ
ログ
20011/07/09 に開催された TDD Boot Camp in Tokyo 1.5 #tddbc に参加してきました。
blog を書くまでが TDDBC なので、当日の様子や感想を時系列で記録してみました。
参加を検討している方などの参考になると嬉しいです。
AM 9:00〜9:30
渋谷駅に到着。
会場であるジンガジャパン(旧ウノウ)に9:30集合だったので、割と余裕を持って桜丘町の坂をひたすら登る。
暑さで朦朧としてると、渋谷インフォスタワーの周辺で@ShiroKappaさんに声をかけられた。
@SHIROCAST さんらと合流することになっていたとか。
しばらく喫煙などして過ごしつつ、@t_wada さんや Symfony 的な方々と合流しました。
ジンガジャパンオフィスに到着。
そしてすでに TA や参加者の方が数名いらっしゃっていたw。
テーブル等は準備されてたので、結局やったことといえばこれくらい。スタッフ仕事になってない。
- 延長タップ用意するとか
- おかし用のテーブルとか運ぶ
- 受付テーブルの準備手伝う
- 無線LAN情報書いた紙をあちこちに貼る
そんなことをしている間に参加者の方は続々と集り、周囲はざわざわとしだしてました。
テーブルをだいたい言語ごとに分けることになり、それぞれのテーブルには言語を書いた紙が載せられてました。
実は当日まで設営スタッフ枠だと思ってたので、自分も参加できることになるとは思ってませんでした。
なので、最後に空いてたそれ以外のテーブルに着席。
AM 10:00〜 PM 00:30
TDD Boot Camp が開幕し、だいたいスケジュール通りで進行してました。
- @t_wada さんの講演
- 「バージョン管理」「テスト」「自動化」が、開発のためのただの3本の柱ではなく、3本の支柱であるというあたりまでは意識がありました
- その、、寝てて聞いてませんでした。ごめんなさい
- でも大体想いは分かってるつもりです
- @ShiroKappa さんによるLT「TDDを採用に至った経緯と期待することを経営、PM目線で」
- 開発者視点でない TDD の評価を公言されてました
- WEBシステム開発[アルティネット]ぱねぇ
- @tomy_kaira さんによるLT「Gitのいろは」
- 「花咲くいろは」コラに対する反応は無かったw
- ステージングとかの言葉使わない Git の説明は初めて聞いたような気もする
この辺でランチタイムになる。
PM 00:30〜PM 01:00
ランチタイム中に @setoazusa さん、@toshikawa さん、@t_wada さんに xutp本(仮)出版プロジェクトについて相談。
結果は第-1回ミーティングにまとめました。
PM 01:00〜PM 01:30
PM 01:30〜PM 05:45
ワークショップ始めるにあたって、@choplin さんとペアを組ませていただくことになりました。
そして「それ以外」の言語ってことでどうするーと話しつつ、node.js 使うことに。
@choplin さんは普段 rhino で js 書いてらっしゃるとのことですが、私 C ですから自信無し...
テスティングフレームワークはGitHub - caolan/nodeunit: Easy unit testing in node.js and the browser, based on the assert module.で。
node.js 付属の assert モジュールを拡張したやつっぽい、シンプルなものですね。
Node.js見ながらなんか作業してたら「npm 入れればいいよ」とアドバイス頂いて、
どういう方法か忘れたけど npm を導入。
結局こうしたのかな?
$ npm install nodeunit
最終的に次のような環境で進めることになりました。
- 言語:JavaScript
- 処理系:node.js
- テスティングフレームワーク:nodeunit
- エディタ:vim
最初は nodeunit の example から書き直してました。
しかし、require したオブジェクトがテストメソッドから参照できない問題がまったく解決できず 30 分くらいはまることに。
時間もないので、しばらくはテストコード中に直接オブジェクト定義していくことにしました。
途中、@choplin さんがうまい解決策を見出してくれて、プロダクトコードとテストコードを分離することができました。
ペア作業の様子を思い出しながら追記してみました。
今回のお題は自動販売機。
- 「千円札と硬貨を投入することができる」という仕様?について、「お金を入れる」というテストを作成
- 空のテストを実行して、成功することを確認
- そういえば以前 assert のないテストメソッドに関する議論がどこかであったような...
- 自動販売機オブジェクト v を追加
- vendor なのか vender なのかで何度も @choplin さんを困らせてしまいました
- vending_machine とかにしたほうがよかった
- お金の投入は
insertというメソッドでできることにしました - 投入された金額は
getCountというメソッドでできることにしました- この辺、名前付けに悩んだりしなかったけど見直すと微妙です
- 自動販売機というメタファからすれば、LED に金額が表示されてるから
displayとかのほうがそれっぽいような気もする
v.insert(1000)の後にtest.equal(v.getCount(), 1000, "insert 1000yen")というアサーションを書いて、テストが失敗することを確認
という感じで、仕様?それぞれについてテストを書いてから仮実装(場合によっては明確な実装)をしていくという作業を延々と続けてました。
三角測量のためのテストを書くってこともしたかったのですが、結構時間短めだったので省略しちゃいました。ナビゲータとしてここははっきり言うべきだったと思ってます。
課題の進め方についてはペアプロという目的からは失敗しました。
形式的には、ドライバーとナビゲータという立場を交代しながら進めていくのがペアプロなのに、私がずっとナビゲータ、@choplin さんがずっとドライバーになってしまったからです。
思い(という言い訳)として整理するとこんなところです。
懇親会
会場までの途中で会話した話題をちょっとまとめます。
お相手の方@remoreさん、初対面でしたが面白い会話をさせていただきありがとうございました!
- 「一度書いたテストを捨てるタイミングはどの時期か」
- 「それでも境界値テストなどは残す価値があるのではないか」
- これには、自身の意見として次のような回答をしました
- 「機能テストが揃った頃に境界値が変わるようなロジックの変更が必要になるケースは逆に少ないのではないか」
- 「であればやはりそういったテストケースも思い切って捨ててしまってもよいのではないか」
会場であるお店に到着。
とても準備よく、到着した時点でもう食べられる状態で準備された鉄板焼/お好み焼きでした。
お店の名前覚えてませんが、桜丘町界隈だと有名なんですかね。
そして PHPer に囲まれてました。
もしかしておしゃれ web 男子さんと同席してたのかもしれません。
個人的には今日の設計どうだったーとかの話題が出るかと思ってたら、近年の Web 開発業界界隈の話や、マージ地獄の話などでした。怖いわーまじで。
冒頭で述べたとおり、すでに前日飲み明かした身では、1日ワークショップを行った後に残された体力は少なく、早々に退散いたしました。
