最近では無くなってしまったのですが...MS.NETでのテスト駆動開発を読み終えました。読み終えて思ったことです。
一般的な例だけでなく、 ADO.NET や Web サービスを TDD で作るといった、 実践的とも言える内容が含まれて好感が持てました。また、システムを検証していく上でのステップについて、改めて考える良い機会となりました。

しかし、この本を読んで思うことは、やはり TDD で GUI を開発することは不可能だと言うことです。FIT による ADO.NET の例が記載されていますが、本当の画面出力を開いてとせず、ブラウザに送られる XML が検証のターゲットです。本当の画面を相手としていないので、現在もまだ主流だと思われるクライアントサーバタイプのアプリケーションに対しては、本書の実例は役には立たない< でしょう。またユーザと開発者のデータの見方はかなり違うので、その辺も実際のテスト現場に落とし込んでいくのはむずかしいかと思います。顧客が外部要求 仕様の一つの項目について注目したとき、その項目はデータベース上では複数の項目や複数のテーブルに表現されている(正規形崩しや、歴史的理由によって) かもしれません。ユーザのテストは、「このエントリからこんなデータを入力した、次にこんな操作をした。だからこういうデータがあるはず、そうすると、こ ういう感じでこの画面には表示されるだろう。」というのが一般的なのではないでしょうか？とすると、TDD での検証も、こんなデータがあるからではなく、「この画面からエントリを入力した。すると関連画面はAとBだから、AとBでこのエントリ内容が確認でき る。」というテストになるのでしょうか？
ただ、GUI 以外の部分については適用できると思います。画面を切り離したクラスについては TDD の有効性が良く表れるでしょう。
でも、予期しない例外に備えるとか、拡張性を持たせるという考えはTDDには無いのだなということも知りました。くろねこ的に最小限の機能しか積まないというのが引っかかります。
将来予想される事項への機能は、拡張性として積んでおきたいたちなので...あと、予期しない例外については、ケースを上げられないことも多く、そのために最近のコンパイラは例外構文があると信じています。ある意味、この点においては、退化なのかなとも思います。

TDDはさておき、くろねこの TJDBGrid にも DUnit などの xUnit によるテストを取り込みたいのですが、機能が多く全体が大きいのとGUI 出力部分のテストなど難題は多く、導入に踏み込めません。

さらに実践に即した現実解を模索する必要がありそうです。
ただ TDD 理解するという目的で .Net 環境で開発する開発者にとって、おすすめです。