C++プログラマ向けのTDD Boot Campに参加してきました。「ブログに書くまでがTDDBCです」とのことなので、参加報告をまとめておきます。
■TDDC BootCampとは？
TDD Boot CampはTDD（テスト駆動開発）について、実習形式で手を動かして体得することを目的とするイベントです。全国各地で開催されているようです。
http://devtesting.jp/tddbc/
今回のプログラミング言語はC++でしたが、他の開催日は言語を複数やることが多いようです。例えば、11/5の横浜はJava(JUnit4)、Ruby、C (cunit)、C++ (Emacs+cppunit/Google Test)、Groovy(Spock)、PHP(PHPUnit)、JavaScript(QUnit)と多彩です。
http://devtesting.jp/tddbc/?TDDBC%E6%A8%AA%E6%B5%9C
■TDD Boot Camp 東京 for C++のプログラム
講演と実習＆レビューの繰り返しでした。みんなが煮詰まってきたら、適度なタイミングで講演やら休憩が入って助かりました。時折、チーム間のレビューや、全体でのレビューが入り、頭の中を整理しながら、課題に取り組めるように工夫されていました。
詳しくはイベント告知ページを参照。
09:30～10:00 開場
10:00～10:05 会場説明
10:05～10:35 中村薫さんによる講演(@kaoru)
10:35～12:00 実習＆レビュー
12:00～13:00 お昼休憩
13:00～13:40 井芹洋輝さんによる講演(@goyoki)
13:40～15:00 演習
15:00～15:30 レビュー、休憩
15:30～17:15 演習（続き）
17:15～18:15 レビュー、ふりかえり
18:15～18:30 和田さんによる総括と締めの講演(@t_wada)
18:30～ お片づけと懇親会
■TDDの演習課題
いわゆる探索の問題でした。
近いうちにどんなコードになるか公開しますので、お楽しみに。
■講演：TDDBC中村ヘようこそ（by @kaorun）
TDDをやる目的や考え方が良く分かる講演でした。内容の詳細に関してはslideshareやブログ記事を参照してください。講演の中で特に心に残ったのは以下ですね。
- バージョン管理、タスク管理、自動化されたテストはプログラマの躾である。
- これらの躾をする目的はプログラマの心と体の健康を保つこと。
非常に納得感がありました。
私の場合、業務でオブジェクト指向設計でテストしやすい構造にしていますが、今思うと「心と体の健康を保つ」を狙っていたように感じます。テストをしやすい設計にすると、単体テストでロジックのミスを検出できるので、実機でのシステムテストが楽になって心が穏やかな状態で開発できますから。
おそらくはTDDもインタフェースを意識した設計にすることを目的にしていると感じているので、オブジェクト指向設計と似た効果を狙っているんじゃないか？と思いました。
ここ1年は「開発者の心と体の健康を保つ」は自分の中のキーワードとして心に留めておきます。
■講演：TDDネクストステップ（@goyoki）
こちらはTDDを実践するときの知識や、今後学習を進めていく上で有益な情報がつまっていました。
テストコードもメンテナンスプログラムである以上、プロダクトコードと同じように保守性を高く保つ必要があるという点が非常に有益でした。テストコードの保守性を上げるには、プロダクトコードを設計するときの同じ考え方で設計することが重要になるようです。
また、なるべくテスティングフレームワークの機能を活用することだと感じました。googletestを調べた感じでは、フィクスチャやParameterized Testなどの機能をうまく使うと、重複を排除できて、テストコードを書く量自体も減らせそうです。
講演中にTDDを学ぶ上での良書を紹介してくれていました。特にお勧めは以下の3つ。
Addison-Wesley Professional
発売日：2007-05-31
レガシーコード改善ガイドは積読しているので、読みきります。
■講演：〆の講演（by @t_wada)
さすがの @t_wada さんで、聴衆が引き付けられる、すごい力がありました。Twitterでめっちゃつぶやいたので、すごい心に残ったものを少し挙げておきます。私が書きとめたものなので、実際に話しした内容とは多少違ってるかもしれません。
- なぜTDDをやるのか？自分が完璧ではないと知っているから。最初から思い通りにできるほど、対象は簡単ではない。素早く対処にちか付きながら、フィードバックを得ながらじりじりと動いて行く。
- 少しずつ動く開発の必要生を感じているからTDDをやる。テストは目的ではなく手段。ソフトウェア工学的なメリとではなく、書いたコードに自身を持つため。テストに通ったなら、少なくとも自分が考えた通りには動いている。
- テスト設計は間引きの考え方。どれだけのテストをやれば全部テストしていると言えるかを考える。
- 知識のインデックスを作る。グラフ、経路、重み。全部知るのではなく、探したいものに対してインデックスを貼っておくことがスキルの差別かにつながる。
- テストが無いコードがたくさんある。その現状に対してどう戦うか？その際にヒントになるのはレガシーコード改善ガイド。どうやって自信のある領域を作って行くか、そのヒントが詰まっている。
- 祈りではなく自信を。新規に書くときはテストコードを書こう。たくさん本を読もう。考え方を知ろう。書籍の中でよく参考文献に上がっている本を読む。
- TDDはスキルである。才能ではない。テストコードを書けばばくほどうまくなる。
@t_wada さんの講演を聞いて心構えは十分だと感じました。あとは実践ですね。業務の品質改善ネタにテストが入っていたので、レガシーコード改善ガイドなどを片手にテストに取り組んでいこうと思います。
■全体を通しての感想
イベント中から懇親会にかけて、組み込み屋さん、ゲーム屋さんといろいろ話しました。皆、業務ではテストコードのないレガシーコードにまみれていて、リリース間近は踏んだり蹴ったりの状態になっているようです。自動化されたテストに対する期待感は高いよう。
だからこそ、TDDBCに疑問を解決するために皆さん集っているようです。その期待に対して、TDDBCはTDDの考え方や実践的なスキルを経験する場として期待にこたえていると感じました。一方で、TDDBCで扱える内容だけで、業務のプロダクトコードに対応できるかというとそうではないと思います。もっと仕様やコードが複雑だし、金も時間もないし、絶望的な状況は多いです。
TDDBCはひとつのきっかけ。もらったヒントを手に、それぞれ自分の戦場でいかに戦うかは自分次第でしょう。
といいつつ、私自身は参加して満足です。しばらく自動化されたテストは自分の中の大きなテーマに設定しているので、継続的に学習は続けようと思います。
■Stay Tuned
近いうちにTest Driven Development for Embedded Cの読書会をやろうと思います。
時期が決まれば仲間を募集したいっす。
Pragmatic Bookshelf
発売日：2011-05-02
