懸田さん
Testing=(UnitTest && AcceptanceTest)
が XP の趣旨であることは、その通りと思います。
この定式から何を読み取るかが異なっているのでしょう。
懸田さんは、Unit Test が不可欠であることを重視しています。
今回の事例では、二つ合わせて、
・ プログラムの intention を test code という形で実現する。
・ プログラムが壊れたら、テストで見つかる。ので、勇気を持って変更できる。
が実現できている、"場合"により、力点の置き方はずれるのでないか、
と捉えました。
で、どういう"場合"があるのか、ですが、
・ いわゆるユーザ・アプリケーション＝機能テストを十分にすれば、
intention を網羅できる割合が高い。
・ COTS 型のアプリケーションやフレームワーク＝ユーザがどう使うか
予測不可能なので、機能テストで網羅できる割合が比較的低い。
ということと考え、今回の"場合"は、前者なので、機能テストを十分にすれば、
いいだろう、という発想です。
くどくなりますが、refactoring をしていく場合、unit test は重要性が増す、
と考えています。
refactoring はどのようなときに有効か、というと、
・ 効率を向上させつつ、機能はそのままにする。
・ 機能が追加されたとき、再利用性を向上させる。
というのが大きいと考えてます。
今回の場合、
・ 効率は、アプリケーションを支える基盤で決まってくるので、アプリケーションの
リファクタリングで、効率が大きく改善される可能性は低い。
・ 機能が追加されたとき、再利用される構造が新たに生み出される可能性も低い、
ということで、refactoring に対する備えを構えてはしませんでした。
もし、refactoring が必要になったら、どうするか？という問いには、
YAGNI と答えます。
こう書くと、XP なんて使わなくても、と思われるかもしれませんが、
ドキュメントをどこまで少なくできるか、プログラマにプログラム以外のことに、
気や時間が取られないようにするにはどうしたら良いか、
という点では、極めて有効でした。
また、超短期開発は、オンサイト顧客無しに実現できない、という課題が早期に
論理だてて合意できたことも、有効であったと考えています。
はだ
At 午後 06:37 01/03/13 +0900, Takeshi Kakeda wrote:
>> XP を前提にしても、
>> そもそも、プラクティスにあるのは、Testing であって、Unit Tests では
>> ありません。Unit test と Function(Acceptance) test の分業？は、
>> ケースバイケースなのではないでしょうか。
>確かにTesting=UnitTestという図式は明言されてはいませんが、XPに関する
>資料を見るとTesting=(UnitTest && AcceptanceTest)というのが私の認識です。
>
>UnitTest = プログラマが作成、実行する
>AcceptanceTest = ユーザが作成、実行する
>
>というように、個々に別々の役割がありますので、両者を行うのがXP的には
>必要だと考えます。