こんにちは、上手です。
ソフトウェアテストのMLで大田さん（Oota Kenichiro）が紹介されていた記事を
読んで、Kent Beck の TDD(Test-driven Development)の資料を調べてみました。
なかなか面白そうなので内容を紹介しておきます。
＃石井さんに紹介されたとか。
http://groups.yahoo.com/group/testdrivendevelopment/files/
TDD17Jul2002.pdf が最新のようです。
これから出版される本の草稿のようですが、大分進んでいます。
３部構成です。（以下、前書きより）
１部：マネーの例 ->Ward Cunnigham からずっと前に入手した「多国籍通貨の計
算」の例による、テストファーストの説明です。
２部：xUnit ->１部の例より複雑でリフレクションや例外を含んだ例を、自動
テストのフレームワークを開発しながら示します。これはxUnitアーキテクチャ
の紹介でもあります。
３部：TDDのパターン ->どんなテストを書き、どうテストするか。例の中で使
われたデザインパターンとリファクタリング。
TDDの概要は、前書きと 35章 Mastering TDD などにあります。
（前書きより）
TDDではあなたは：
・自動テストが失敗したら新しいコードを書く
・重複を取り除く
２つのルールはプログラミングのタスクへの命令を持つ：
・赤 − 動かない小さなテストを書く。最初はコンパイルもできないかもしれ
ない
・緑（青） − 必要なら（悪い）こともやって、手早くテストを通す
・リファクタ − テストが動くようにしながら、重複を取り除く
Red/Green/refactor はTDDのマントラ（呪文）です。
それでは、私（がこのコンセプトを考えたこと）の動機は？ 何でプログラマは
自動テストを書くのか？ ・・答えは勇気。
TDDはプログラミングの恐怖を管理する方法です。
・自信がない状態ではなく、できるだけ早く、確固とした状態から始める
・冷たい関係ではなく、よりはっきりと情報を共有する
・フィードバックを避けるのではなく、役にたつ、具体的なフィードバックを捜
す
XPとTDDは違う。
一週間設計し、コーディングをテスト駆動にしたら、それはTDDか？ -> YES
34章には、KB流のリファクタリングの例が出ています。
38章には、フィボナッチの例が出ています。
では、お楽しみを！
yutaka