TDD本は凄いぞ！

　04/9/21発売の「バグがないプログラムのつくり方 JavaとEclipseで学ぶTDDテスト駆動開発」
以下「TDD本」と略記）を改めて読み直しました。
　PG初心者だけでなく、経験者も惹きつけるだけの内容があります。
　僕が興味を抱いた箇所は下記の通り。

【１】TDDとトヨタ生産方式の比較

　プロジェクトにTDDを導入する時、メンバーを巻き込むのはあまり労力がかからないだろうが、上司にTDDの良さを納得してもらうのはたやすくない。上司がオブジェクト指向をマスターしていれば、TDDのコンセプトを説明するだけで承認されるだろうが、普通は構造化の世界に生きているから、まずありえない（笑）
　では、どうすればTDDの良さを上司に理解してもらえるか？
　TDD本では、「トヨタ生産方式」と持ち出して、TDDのコンセプトと似ている例をあげている。
　例えば、後工程引取方式は、TDDでいうSimpleな設計に当たる。つまり、後工程引取方式とは、後工程が前工程から必要な部品を調達していくという引算の発想であり、JustInTimeの考え方そのもの。TDDなら、テストプログラムを最初に作ることで、開発モジュールのインターフェイスを考えるようになるので、無駄な実装はしなくなる。「徹底した無駄の排除」を貫くトヨタ生産方式とYAGNI原則を貫くTDDは、コンセプトが非常に似ていないか？　「自働化」は、TDDなら「テストの自動化」に相当しないか、と。
　この説明を読むと、最近のアジャイル開発の翻訳本がトヨタ生産方式を絡ませている理由の一つが分かります。

　又、管理者にとってもTDDは進捗管理に役立つ。ウォーターフォール開発で進捗80％と報告を受けても、プログラムはできていないのだから、本当の進捗は10％かもしれないのに、検証する術がない。しかし、TDDなら、テストプログラムでカバレッジを測定できるので、実装ロジックの80％が完了している、という事実を数値で知ることができる。
　更に、システムを前任者から引き継ぐ時、管理者としては、ドキュメントとソース一式よりも、テストプログラムとソース一式の方が嬉しくないだろうか？　ドキュメントなんて、保守フェーズですぐに古くなるし。テストプログラムがあれば、引き継いだプログラムの単体テストは保障されているからね。

【２】モックオブジェクトを使ったテストプログラムと依存性注入（Dependency Injection）の説明は非常に分かりやすいです。

　ソースを読むと分かるのですが、モックオブジェクトはインナークラスを使うんですねえー。インナークラスはThreadを使う時しか見かけなかったけど、こういう使い方をするんですね。
　インナークラスをCreateすることでモックオブジェクトを生成するロジックを、xxx.diconに書かれたコンポーネントをSingletonで呼び出すロジックに変えたら、あらま、Seasarそのままじゃないですか！
　Dependency InjectionはFactoryMethodの変形パターンと解釈していいのだろうか？

　TDD本はお勧めです。是非、皆さんもご購入を(^^)