2012/04/06(金)はyujioramaさん主催のTDDカンファレンスでLTしてきました。
TDDBCなどで活躍されている皆さんに混じって発表するのは、少し気後れするところはありましたが、いい機会がいただけて良かったと思います。
発表に使ったスライドは↓↓。
TDDは後々まで使えるテストを生んでくれますが、ベースは設計技法だと思ってます。
インターフェースを設計する力が無ければ、TDDを実践するのは不可能です。
そもそもできないものを書けるようにしてくれる魔法ではない。
一方で、ある程度やれるなら、ゆるくTDDを始めることで、段階的に設計力を身に付けることができるやり方だと思っています。
TDDの原則として掲げられていることと、厳格に一致しなくてもいい。
最初はコードを書いてから考えてみる、横にあるとりあえず書いてみたコードをリファクタリングするために、そこからTDD的に書いてみることから始めてみてもいいと思います。
教科書的にやらなくても、身近なところから書いていけば段々慣れていきます。私はそうやってTDDというやり方を身に付けてきました。
これからTDDをやる人も、原則に捉われずに、見えるところからやっていくのはどうでしょうか？
後、ジョジョにおいて最もTDDだと思うスタンドは「クラフトワーク」です、というジョジョエバンジェリスト活動もやってきました。
TDDをやっているジョジョ読者は是非、覚えておいてほしいスタンドですねw
ディスカッションでは、TDDをこれから導入するにはどうすればいいか、というテーマで話をしていました。
TDDやると工数増えるんじゃないの？→むしろTDDやらずにユニットテストをどうやって書くのか？ユニットテスト無いと確実に工数増える。
TDDの勉強会にチームメンバーを引っ張りこんでみるのはどうか。いきなり勉強会は結構心理的ハードル高いので引っ張ってくれる人が居ると楽かも。
あんまりテストファーストで書けてないんだけど、これはTDDなのか。→実装とユニットテストが小さなサイクルで回っていて、継続的にリファクタリングできてるなら、原則とか気にしなくてもいいのでは、十分TDDだと思う。
などなど、このあたりが記憶に残った内容でした。
今回、Rubyistとして、一度お話ししてみたかったukstudioさんと懇親会で話ができてとても嬉しかったです。
RSpecの話について少し話を聞くことができました。
テストコードの見易さについて、もうちょっと意識してみようかなと感じました。
後、懇親会後、最終的に朝まで付き合ってくれたkunitooさんに感謝。
ポジション的に親近感を覚える感じで、ゆっくりお話できてよかったです。
またよろしくお願いします。
