（続）テスト駆動開発（TDD）ってそういうことだったのか
昨日のエントリでは「”TDDにおけるテスト”を”品質保証のためのテスト”として扱ってよいのか？」という疑問が残った。
この問題に関連して、An Agile Wayの平鍋さんはテスト駆動開発のテストは、テストか？−TDD から BDD へというエントリで、Brain Marick氏の次のような発言を紹介されている。
アメリカでのコンセンサスは、TDDのテストはテストとしては二義的であり、一義的には、「設計ツール」だ
また、同じエントリで紹介されているt-wadaさんの「Test」という言葉について(PDF) は非常に参考になる（納得感あり）。とくに、
- TDDは「こうしてみようか」をテストする
- QAテストは「こうあってはならない」をテストする
というくだり、うまい表現だとおもう。そのほかにも印象に残ったスライドを引用しておく：
- TDDはテスト技術ではない
- "Test"が指し示しているものは複数ある
- 開発促進と品質保証
- 2つの"Test"に優劣はない。「違う」だけ。
- どちらも非常に重要
- テストをロールから分類する
- 開発者 / 顧客 / 品質保証担当者
- TDDの"Test"は開発(者)のためのもの
- つまり、開発促進のテスト
- TDDの良さは設計技術でありながら品質保証技術に「かなり近い」こと
TDD != 品質保証技術
- TDDは「こうしてみようか」をテストする
- QAテストは「こうあってはならない」をテストする
TDD != 開発プロセス
TDD != テストファースト
- テストを先に書くかどうかが重要なのではない
- テストを先に書けばTDDというわけではない
- テストを後から書くTDDもある
- TDDはテストを書いて実行するという行為からフィードバックを受けて先に進むことを意識している
- 「直前に書くことと直後に書くこと」の差はそんなに大きくない
TDDは設計技法です
- プログラミングは設計行為である(J.Reeves)
- REDは仕様の設計
- GREENは仕様の実装
- Refactoringは内部設計の改善
TDDを行うと、何がお得?
- 「自信」「安心」
- 自信をもって機能を追加できる
- 自信をもってリファクタリングできる
- 設計改善
- 軽微なバグの予防
- SbE(Spec by Example)
- 動くドキュメント
- 動くサンプルコード
