自己レスです。
At 午後 09:03 01/03/12 +0900, Hada Akihiro wrote:
snip.
懸田さん曰く
>>またUnitTestなしのRefactoringも非常に辛い気がします。このあたりをどのよう
>>に回避していたのかも気になります。
snip.
>>私がお客さんにXP(というかJUnitによるTesting)を紹介した時に「短かい納期でテス
>>ト書い
>>ている時間があるのか？」と反論されたことがありますが、この記事のプロジェ
>>クトも同様の理由でUnitTestをはしょったのでしょうか...
>このお客さんの"時間があるのか"という質問の意図が不明ですね。
>納期が、短かろうが、長かろうが、
>書く必要のあるテストは書き、必要の無いテストは書かない。
>仕事なのですから。
XP にとって、Unit Test が肝であるのはそのとおりだと思います。
それは、Refactoring は Unit Tests 無しに成立せず、Refactoring なしに simple
design
は困難。更に、simple design 無しに、"変化ヲ抱擁セヨ"は実現できないから、
と考えます。
くどく敷衍すれば、
Refactoring は、機能、振る舞いの変更無しに、内部的な構造を改善すること、
と理解しています。
これができるから、big front
の設計無しに、シンプルにコードィングし、必要に応じて、
再設計していけば良い、という方針が実現できる、というのが simple design。
そして、
これを保証するには、対象となるコードの外側に、intention
を書き、機能の変更が無いことを
テストで検証する、これを纏めると、Unit tests として intention を書く、
ということになるというのが、 Unit test の趣旨でしょう。
と、なります。
今回の事例では、Refactoring する余地の無いほど、単純なアプリケーション
（システム全体としては、単純ではありませんが）なので、
Unit Tests が必要ではなかった、というのが前回のメールの趣旨です。
その代わりに、
・ インタフェースとそれに対する JavaDoc 記述により、実装の外部に intention
を書く。
・ 言語的、システム的に発見できる誤りは、コンパイラやコンテナに発見させる。
・ アプリケーション的な誤りは、シナリオをコード化した、機能テストで発見する。
という従来法で、実現したということです。
Refactoring tool でも、言語の reflection 機能を利用して、誤りを発見する、
Refactoring を自動化する、ということをしている訳ですから、そんなに邪道では
ないと考えています。
で、改めて考えてみますと、
このお客さんの質問の趣旨ですが、XP の Unit Test には、従来の単体テストに
含まれない、intention の記述が付加されていることを指摘しているのかな、
と思いました。
はだ