今日は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と黄金の回転」
