TDDでアーキテクチャを導出出来るか
この対談、面白い！必見ですよ、必見。
概要
Coplien氏とMartin氏、TDDとCDDそしてプロフェッショナルの定義について大いに語る。
JAOO '07 で「今時、ユニットテストを実施してないコードを納品するのは無責任な開発者だ」というBob Martin氏の主張について、議論が起こった。このInfoQビデオは、BobとJim Coplien氏がこれに関連する話や、いくつかの他の話題について議論する様子を納めたものだ。TDDと契約による設計(Design by Contract)の比較や、システムとビジネスドメインモデルを調和させるためには、事前にどれくらいのアーキテクチャ設計をしておかなければならないのか、などが議論されている。（翻訳：近藤 修平 - (株)永和システムマネジメント）
見ながら思ったことをメモ。思考が色んなところに飛び火したので、対談の内容とはあまり関係ないことも書いてある。
TDDはプロフェッショナルの条件なのか
Bob Martin 氏は「ユニットテストの書かれていないコードを納品するのは無責任だ」と言っている。そんなのはプロのやり方じゃない、というわけだ。一方で、僕は次のような意見も聞いたことがあって、それはTDDのテストはあくまで開発をドライブするためのテストであって品質を保証するためのテストとはなり得ないというものだ。
Bob 氏の発言の意図が、品質の検証がされてないコードを納めるのは無責任だ、という意味であるならば、TDDをしたところで品質保証にはならない気がする。
TDDはアーキテクチャの変更を受け入れるか
XPのスローガンは Embrace Change であって、変更に立ち向かうためにはテストが必要であって、そこからTDDの考え方が生まれた。この文脈で語られる「変更」とは顧客の要求の変更であって、いわば上流側の変更に対して下流側がどう立ち向かうか、という文脈だと思う。（上流、下流という言い方がいいかどうかは別として）
これに対して、逆の変更、すなわち下流側の変更に対してもTDDは有効な武器になり得るのだろうか。つまり、より低位のアーキテクチャレベルでの変更が必要になったときにも、TDDは有効に機能するのだろうか。
僕はこれに関してはちょっと疑問を持っている。アーキテクチャが変更になるとクラス構成が大きく変更されてしまうので、テストの構成もそれに合わせて大きく変更しなくてはならないのではないか。事実上、テストの書き直しになってしまわないか。その事実が重たい足枷となって、本来変更に立ち向かうために書かれた筈のテストの存在が、返ってアーキテクチャの変更を躊躇わせることにはならないだろうか。
