書籍：実践テスト駆動開発

実践テスト駆動開発 (Object Oriented SELECTION)

実は、ちょっと不満がある。だた、この不満は、オブジェクト指向設計／テスティング活動ついての、きわめて個人的な信条／大切に考える価値判断に由来している。個人的な不満。

この本は、オブジェクト指向設計、テスティングが主題なのだが、どうしてドメインエキスパートとの対話をあまり描かず、OOやテスティングを説明したのだろうかと（対象を明瞭に記述しようとするこだわり／気配りを凄く感じるのに）。DDDが、がんばって対話について説明しようとしたように、もう少し触れてほしかった。 Fitががんばって説明したように、もう少し触れてほしかった。
著者は、ドメインエキスパートとの対話は開発の大前提だから、詳しい説明は省力してよいと判断したのだろうか。OOがテーマなのに？テストがテーマなのに？

「複数のロールの人々が、対象ドメインや仕様を深く『理解する（合意する）』のに、いったいどのような過程をたどるのだろうか？どうすれば誤解がとけるのだろうか？」

開発者が対象ドメインや仕様を積極的に知ろう理解しようという行動や意志は欠かせない。ドメインエキスパートが開発に積極的に関ろうとすることも欠かせない。
もし、開発者とドメインエキスパートとの対話が欠落した場合、誤った認識をもとに、ソフトウェアやテストを記述することになる。対話が欠落すれば誤った記述を見つけ、理解しなおすプロセスも欠いてしまう。誤解に基づいたこの濁ったソフトウェア-テストの記述は遅れて問題発覚する。開発者とエンドユーザーは時間的／空間的／心情的に距離があるため、1ヶ月、3ヶ月、６ヶ月と発覚は遅れる場合もある。遅れての発覚はたちが悪い。誤解に基づいた濁ったソフトウェアは、開発者／ユーザの心を濁らせ、信頼関係を破壊してしまう。過去になんどかやられている。

DDDが描画したように、ドメインエキスパートと開発者が対話しながらコード-概念モデルをより明瞭に記述していこうとするのが私の理想解。アートオブアジャイルディベロップメントやSpecification By Example が描画したように、ドメインエキスパートと開発者がペアになって対話しながらテスト（仕様の具体例）を明瞭に記述していくのが私の理想解。なかなかできないんだけどね。

反則的に、本にあまり書かれていないことで、不満を書いたが、この本は、ものすごくおすすめっす。

本題からはテスト駆動がメインになっていますが、テスト駆動にあまり興味なくても、オブジェクト指向に興味のある人も、ぜひ手に取ってほしい一冊。原題は、Growing Object-Oriented Software, Guided by Tests ですからね。タイトルは実践テスト駆動開発となっていますが、ケントベックのTDD本から連想するテスティングの活動の範囲にとどまらず視野が広い。実践的なアドバイスが多数記載されている。
本番に近い環境で動くスケルトンを早い段階で自動デプロイし、動作することを確認するのは大変だけど重要ですよね！テストコードだけではなく、リーダブルなテストレポートになるように手を加えるあたり。ALLテスト失敗時に、テスト失敗レポートがイミフ、テストコードがイミフで苦しんだことがある人ならウンウンとうなずくはず。テストデータのセットアップで整理できずに混乱したコードを書いて、苦しんだことがある人ならウンウンとうなずくところがあるはず。オブジェクトに不純物が混ざって、ユニットテストが書きづらい、なんとか設計を改善したい感じたことがある人ならウンウンとうなづくところがあるはず。オブジェクト指向設計でここまでメッセージングにこだわって注意を向けるあたりは、他のOO本にはない何かを感じ取り「うーん。OOっていったい何だろう！？」と再考させてくれるはず。

オススメっす！