TDDBC 大阪 2.0

6/3（日）に開催された TDDBC に参加しました。
会場の楽天カフェテリアはおしゃれな感じで、さすが楽天といった感じでした。
スクリーンもとても見やすく、勉強会として使用するのに理想的な会場でした。

当日のタイムテーブルは次の通りです。

  • 和田 卓人[twitter:@t_wada]さんの講演
  • 吉岡 弘隆[twitter:@hyoshiok]さんの講演
  • [twitter:@irof]さんと和田 卓人[twitter:@t_wada]さんによるデモペアプロ
  • 演習
  • 関 将俊[twitter:@m_seki]さんの講演
  • テーブルレビュー
  • 講師・TAによるトークセッション
  • ふりかえり
  • 和田 卓人[twitter:@t_wada]さんのまとめ

概要

テストを次のように分類したとき、TDD では Developer Testing を扱います。

  • Developer Testing
  • Customer Testing
  • QA Testing

Developer Testing とは、

テストのことです。
TDD の目標は、動作するきれいなコードです。
動作するきれいなコードを作成するために、

  • コードの健康
  • チームの健康

をテストで担保します。
テストを先に書くのは、ユーザ側にまわらないと分からない設計上の課題があるからです。
使いたいメソッドと作りたいメソッドとはきっと違います。
そういう意味で、TDD はテスト技法ではなく設計技法であると言えます。

演習では、同じ言語(C++)を使用する人とペアプログラミングしました。
テスティングフレームワークはCppUnitを選択しようかと思っていたのですが、C++の TA をしていただいた[twitter:@goyoki]さんに、

CppUnitはその作者も失敗作だと言っている

ということを教わり、急遽googletestを使用することに変更しました。
という訳で、まずはテスト環境を導入して環境を確認しました。
後は愚直に TDD のサイクルを繰り返して課題を進めていきました。

感想

やっぱりコードを書くのは楽しいです。
TDD のリズムを体感できたことはとてもいい経験になりました。
Red -> Green -> Refactoring のリズムは、やってみると、心地よかったです。
リズムを守ってコーディングするのは楽しくて、テストがあるので安心してコーディングを進めていけます。
これをやらない手はないと思いました。
また、人にコーディングを見られ続けるペアプロはなかなか刺激的な体験でした。
ただ、体力/精神を消耗するのは間違いないです。
適度に休憩を取る必要がありそうです。

あと、[twitter:@goyoki]さんに、

組み込みなら、Cpputestがいいですよ。

と薦められました。
今度試してみたいと思います。

それから、グリーンバンド買っちゃいました。

acts as professional

業務中、忘れずにつけています。

テスト駆動開発入門

テスト駆動開発入門