TDD の本を読んだり、TDD の勉強会に参加したりしたので、
さっそく仕事でも TDD をやってみています。
「机上でしっかりデバッグしろ」「端末の前で考えるな」的な教育を受けてきた人間なので（昔はマシンが貴重だったからね）、
「動かしながら設計する」「動かしてみて設計を変える」ということに少し遠慮があるのですが、
やってみると一心不乱にやれる感じがあり、なんていうか「快適」です。
プログラマの本能に直撃！！なのでしょうね。
やり始めるとあっという間に３時間を超え、久しぶりに集中してコーディングしました。
初回だったので、イチから書くことばかりで、見えているボリュームがそこそこあって、
そのため立ち止まって考えることがなくて済んだ(*1)ってのもあるのでしょう。
それから、
完全に新規追加する機能だからとか、
Android のネイティブ部分で POSIX API で書けるとか、
ハード依存部分はスタブで十分いけるとか、
そういった好条件があったので、Windows (gnupack) 上でイージーに作業できて煩わしさがなかったってのもあるでしょう。
残念ながら、テスティングフレームワークは使ってないのですけどもね。
それでもテストをうまく使って、0 → 1（N は未着手）(*2)で関数を進化させたり、
仮実装でどんどん I/F（関数）を追加して、全体のしくみや挙動（仕様）を整えていく感じなど、
TDD らしさを実感しながら少しずつ学んでいってます。
ちなみに「TDD の三原則」(*3) はぜんぜん気にせず、ゆる～くやってみています。
あ、そうそう。TDD 勉強会でご紹介のあったプレゼン資料があったので。
Bowling Game Kata.ppt - ButUncleBob
こんなに短いサイクルでいいんだなー、と。私もほんとにちょくちょく気軽に動かしています。
と、何気ないときにテストの間違いに気づいたりもします。
テスト仕様書を書いて、レビューして、というのとは、少し時間軸が合わないですが、
そのへんも含めて、うまく仕事の中で使っていけるやり方を見つけていきたいなと思います。
(*1) ある程度のラク書きをした上で臨みました（いつもそうします）。仕組みや、登場人物（モジュール）と I/F くらいのことは。
(*2) 「0,1,N パターン」のこと。これの P.23 にあります。
(*3) 同じくこれの P.38 にあります。
