今日はTDDBC 福岡2の講演を聴きながら取ったメモを転載。

TDDとは何か、なぜTDDするのか、どのようにTDDを進めていくのか。
テストは目的ではなく手段であり、真の目的は「健康」。
TDDはスキルだから誰でも習得可能。

といったことが凝縮されている。

TDDとは

まず動くコードを書いてそれをきれいにしていくのがTDD。
きれいだけど動かない設計より汚くても動くコードを書いて、それを徐々にきれいにしていく。

ソフトウェア開発においては、まずコードを書いて動かしてみないと分からないことが多すぎる。
なのでコードを書き始める前に設計に力を尽くしても無駄になる部分が多い。

完璧な設計をしてからコードを書き始めようという「完璧主義の呪い」
（一方で設計しなさすぎも死ぬけど）

TDDのサイクル

1. テストを書き
2. そのテストを実行して失敗させ (Red)
3. 目的のコードを書き
4. 1で書いたテストを成功させ (Green)
5. テストが通るままでリファクタリングを行う (Refactoring)
6. 1〜5を繰り返す

TDDと黄金の回転

• Red → Green → Refactoring
• Red → GreenをうろうろするだけではTDDではない！（動くコードはできるがきれいなコードにならない）
• リファクタリングには意思が必要
• 納期に負けてついおろそかになるが・・・そうなってはいけない
• こまめにやるのが一番楽
• 例えば部屋の掃除のように。ためてためて大掃除になるといろいろと大変

TDDのこころ

• ひとつずつ、少しずつ: 大きい問題を小さい問題に分解して対処する → スキルの領域 訓練でなんとかなる
• ひとりずつ仕留める: たくさんの相手がいても、同時に向き合うものはひとつに絞る
• すばやくまわす: テンポやスピードは重要
• 自分が最初のユーザー: Howに縛られず、WhyやWhatの視点で書き始めることができる
• 道具にこだわる: ツールは大事。エディタ、IDE、テンプレート、プラグイン 開発者の心得
• 不安をテストに: 何に対してテストを書いたらいいか→何に対して不安を抱くか→その不安に思ったことに対してテストを書こう
• 祈るのではダメ: リリースのたびに祈る羽目になる。テストがないと。
• テストが命綱: 壊れたところがすぐわかる。

なぜTDDをするのか

• 私たちは完璧なプログラマではない
• 最初から思い通りにコードが欠けるほど、私たちは賢くない
• 最初から思い通りに動作するほど、対象は単純ではない
• 素早く対象に近づき「フィードバック」を得て方向修正しながら開発を行う必要があるから

テストは目的ではなく手段

最大の理由は心理的なモノ

• 即座にフィードバックを得るため
• 書いたコードに自信を持つため
• これから書くコードに自信を持つため

TDDの真の目的

「健康」

• 変化に対応できるのは健康体の「コード」
• 変化に対応できるのは健康体の「チーム」

不安を克服して健康を維持する

TDDはスキルです

• 才能ではなく、習得可能です
• 量は質に転化します
• 写経しましょう

「技術書の写経の方法」でぐぐってみよう

ひとつだけ覚えて帰って貰うなら

「TDDと黄金の回転」