TDDの基本的な考え方について

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