TDD Boot Camp 札幌 2.0に行ってきた - How to disappear completely

TDD Boot Camp 札幌 2.0 : ATNDに行ってきた。
去年の秋くらいにTDDBCなるものがあるらしいとの情報を得てからTDDとはなんぞやと思いつつも手を出してこなかった僕ですがいよいよ札幌で幾度目かになるTDDBCに参加してみちゃったりしました！

当日、会場に着くなりあまりの頭の痛さに打ちのめされそうになりました・・・寝不足だった・・・

id:shuji_w6eさんのTDDとTDDBCの紹介が、お話がうまくて面白かったです。
各言語の班長のLTも楽しめました。
id:t-wadaさんのTDDのおはなしは、なるほどなるほどと思いながら聞かせていただきました。(テストの無いコードはレガシーコード。ちぃ覚えた！)

すみません。このへんで10分くらい寝かせていただいたのは僕です。

午前中はそんなこんなでちょっとぼーっとしましたが・・・いくつか覚えてるうちに此処に書いておこう。

"汚くて" "動かない" コードから "きれいで" "動く" コードに到達するための2つのpathがある。
1つはきれいで動かないコードを経由する道。もうひとつは汚くて動くコードを経由する道。
動くコードをまず作ってからリファクタリングをしたほうがうまくいく。

動くコードかどうかはテストで常に検証できるから安心！

そういえば同じような話がC++ Coding Standardにもありました。

正しいプログラムを速くする方が、速いプログラムを正しくするよりも、はるかに、はるかに簡単だ。
[C++ Coding Standard 8.時期尚早な最適化を行わない]

速くにあたる部分は速くする以外にも、プログラマーの宿命として、綺麗に書きたいとかもあると思うので、テストを使って常に挙動を確かめながらコードをいじることができるのは大事ですね。

そしてテストを書くことでプログラムの仕様が明らかになるという利点もあります。テストから書くというのはなかなかトップダウン的というか、ゴールからの逆算的ですね。要求から仕様を明確にできるので、そのようなテストを特に仕様化テストなどと言ったりするそうです。ここでいう明確っていうのは、単にプログラマの頭の中とか、分厚い仕様書の中とかではなくて、プログラム上で明確であるっていうのが素晴らしいです。

そしてTDDの真価はここから発揮されて、

仕様を明確にしてくれるテストを書く。
↓
テストで明確にされた仕様を満たすコードを書く
↓
テストを満たしつつよりよい実装を書く(リファクタリング)
↓
さらに機能をつけていく・・・その時に
仕様を明確にしてくれるテストを書く。(大事！)

このサイクルがTDDの黄金の回転らしいです！

しかし、テストから書き始めるというのはなかなか強い意志が必要ですね・・・TDDBCに出た方はすべてのテストをパスすることを連想する緑色のリングをもらって常に自分をTDDの強い意志に奮い立たせるそうです。（僕は緑色のリングもらい忘れたｗｗ）

実際の乱取り形式ペアプロTDDの実践はC++班を組んで、[twitter:@asari755]さんと[twitter:@h_hiro_]さんと僕と3人で行いました。asariさんのPCだけがモニタに繋げられたので、そのPCで乱取りをすることになったのですがasariさんのPCにC++用のUnitTest用ツールが何も入ってなかったので最初にCppUnitの導入から始めるというかなり実践的なスタートとなりました。
でもCppUnitはソースを落としてきて、make; make installだけですぐにはいったので楽でした。

で最初の4時間くらいは、3人ともTDDがほとんど経験がなかったので、演習用課題のうちで簡単な方からテストを順番に交代しながら実際に書いていって、徐々により高次のテストを書いて、テストを充実させていきました。

最終的にその演習用課題のプログラムに充分なテストが揃った段階で、(図書の貸出Databaseを意識したようなプログラムだったのですが、毎回ファイルにアクセスするのではなく、データベースのロード時にメモリにすべて読み込んでみるというふうに)課題のプログラムをリファクタリングしてみました。

その間はテストはいじらないで、Databaseのクラスだけをいじるようにしました。その途中でセグメンテーションフォールトを起こしちゃうなどC++のおちゃめな一面を垣間見ながら、しかし20分くらいで無事に変更をすることができました。

テストが充実していたおかげで、プログラムがその内部の変更に対して守られている感じがとても嬉しいです。変更の影響がテストの結果として明らかになり、フィードバックが得られるのも非常に有益です。

これらによって、リファクタリングするときの機動性がテストなしの時とは比べ物になりません。t-wadaさんがテストを書けばデバッグがほとんど要らなくなると言っていましたが、それはたしかにその通りだと思いました。(セグフォが出たときはGDB使ったけどｗｗｗ)

C++などの静的型付け言語では、型に基づいた静的エラーチェックがあり、プログラム全体の実行時の結合テストもありますが、その間にさらに単体テストがあることで、プログラムの信頼性がより高まると思います。

TDD非常に面白かったです。懇親会も楽しかったです！前回札幌C++勉強会に来ていただいた方にも挨拶できました！（もっといろんな人とお話できたらもっと嬉しかったです＞＜；）

翌日にもTDDBCのサービスパック(SP1)があったのですが、僕は友達とお出かけの予定があったので行けなかった・・・

そして、金土日と、[twitter:@dasoran]がうちに泊まりに来てました。

日曜の夜には、TDDBC SP1帰りのdasoranと[twitter:@nakayoshix]さんと[twitter:@sumim]さんとカラオケに行ってきました。プログラマ4人でカラオケ！

sumimさんが一曲目からSmalltalkの本質でしたｗすべてのものはメッセージですね！nakayoshixさんの歌う洋楽が結構好きな感じでした。興味持ったので何曲か聞いてみよう。
そらんは結構はじけていてよかった！すごく楽しかった！

土日はいろいろと忙しかったですが楽しかったです！ありがとうございます！そらんおつかれ！