日々常々

ふつうのプログラマがあたりまえにしたいこと。

TDDBC 福岡 1日目 午後のメモ

1日目午後はTDD&ペアプロ体験でした。
最初のお題はFizzBuzz

  • 3の倍数はFizz
  • 5の倍数はBuzz
  • 3と5の両方の倍数はFizzBuzz
  • 他はそのまま

頭の中に実装はあるんですが、それは破棄してすることにしました。実装が先に見えきってる実開発なんてあまり無いですしね。
ペアを組んで頂いた @ さんの指摘に実業務だと無視しがちなところだなーと感心したり、人に見られてコーディングする機会って無いなーとかで非常に新鮮でした。
TDDの順番は以下になります。

  1. テストを作る。
    • 実装クラスはまだ作らない。
    • 1実装クラス1テストクラスか、別の単位かは宗教戦争
    • テスト対象の質によって使い分ければいいのかな。
  2. テストメソッドを作る。
    • 日本語メソッド名を使うのをためらわない。
    • ぱっと見たときの判りやすさが大事。
  3. assertから書く。
  4. Red
    • 仮実装の途中でやることになるかな。この時点だとコンパイルが通らないし。
  5. 仮実装を行う。
    • 実装クラスはまだ作らない。
    • 書いたテストに対する仮実装をテストクラス内に記述する。
      • ここではテストコードのテストを行っている。
      • 複雑なテストだとテストコードにバグが混入する可能性がある。
      • 仮実装の本質はテストコードのテストにある。
  6. Green
  7. (ここでRefactoringが入るはず)
  8. 次のテストを書く。
    • 同じテスト対象に対する別テストを書く"三角測量"を行う。

これの繰り返し。慣れてくると仮実装&三角測量がまどろっこしくなるので、不安が無いなら手順を省略し、明白な実装を行う。


TDDのテスト対象はあくまで開発者の不安であり、不安が無いものはテストする必要がありません。それでバグっていたならば、次は不安に感じるはずなので、テストを書けばいいのです。テストコード内に書かれた仮実装を実装クラスに移動するタイミングがわからず、仮実装のまま終了時間を迎えました。

出来たもの

実装は一番下のメソッドです。仮実装を繰り返してるうちは酷い事になっていたのですけど、終わってみればそこそこ読める感じになっていました。これがTDDだ(適当