懸田さん
「単純」でも、「UnitTest」を含めるのが XP の趣旨であることは同意します。
しかし、
・「リファクタリングに必要」→リファクタリングするほどの複雑さではなかった。
・「毎回テストが通るのが快感」→（これがほんとかどうかは不明ですが）
extreme
でない単体テストはやっているので、この要素を捨てている訳では在りません。
・
「プログラマに勇気を持たせる」→プログラムを壊すと、テストで見つかる、という
のは
勇気を持たせることは実感できました。
しかし、実際のところ、自分で作ったテストが通ることより、
機能テストのように別の眼で見て作ったテストが通ることのほうが安心感が
大きいようです。
で、
ここまで考えると、リファクタリングする必要が無い場合、いわゆる単体テストを
越えた unit test をするかどうかは、プロジェクト毎の判断でも良いのかな、
というのが今回の考え方です。
はだ
At 午後 06:37 01/03/13 +0900, Takeshi Kakeda wrote:
>> 単体テストはしていますが、(extreme な)Unit Test
>> はしていない、ということです。
>> つまり、
>> ・ 単体テストに、testing framework を利用していない。
>> ・
>> 単体テストを、インテグレーション時に自動的に行なうようなことをしていない。
>
>> ・ 単体テストを、コーディングより先にしていない。
>> ということです。
>>
>> なぜか、というと、端的に言えば、アプリケーション・ロジックが単純である。
>> ということです。
>> 単純なアプリケーション・ロジックである場合、コードの外側に、intention を
>> 書く必要があると考えていません。
>> （オブジェクト指向言語なのですから。）
>> 実際、JavaDoc とシナリオで十分でした。
>> では、例外的なこと（失敗すべきテスト）はどうなるかですが、
>> ・J2EE 環境で開発していて、失敗すべきテストは、
>> 基本的に環境に任せればいい。
>> ・システム的、言語的には把握できない"失敗"は、
>> function test で書けばいい。
>> と考えました。
>(extremeな)UnitTestは意図的にはずしたということですね。「単純」というの
>がどの程度かわかりかねますが、XP的に考えるならば「単純」であっても
>「UnitTest」は含めるものだと思います。
>
>今回の事例に関しては、「単純なので必要ない」が「リファクタリングに必要」
>「プログラマに勇気を持たせる」「毎回テストが通るのが快感」などといった
>UnitTestによるメリットを上回った、もしくはXPが目的ではないので無理して
>採用する必要はないということでしょうか。