安井＠Aspacです。
Shin wrote:
> Tue, 04 Mar 2003 13:46:11 +0900
> 安井 <yasui@....jp> さんのメールから
> |Shin wrote:
> | たとえば、ATMの手数料を計算するときに「すべての日時に対し
> |て計算する」というものを、「曜日と時間帯に対して計算する」よ
> |うに具体的に落としていく方向で考えています。そしてテストでは、
> | ・平日(たとえば月曜)、土曜、日曜
> | ・料金の変わる時刻の前後
> |の組み合わせだけについて記述します。
>
>
> 私のいいたかったことは、この例だと、問題を考えているときは
> 「平日」というわれわれにはわかりやすい概念を使っているのに
> テストを書くために、わざわざ「2003年3月3日」などという特定
> の日付を使っているということです。
> 数字の上からは、平日は無限に存在しますよね。
たとえば、
・日付から曜日を導く
・曜日から、平日か土曜か日祝日かを導く
・平日/土曜/日祝日から、手数料を導く
というふうに分解してそれぞれをテストしても、最終的には「無限
の日付から曜日を導くテスト」は必要で、そこを特定の日付だけで
書くのは
Shin wrote:
> それを、実行可能なテストにするために、そういう無限の世界から、
> 有限の世界におりてきて、特定の値のテストを書く。そういう
> ことをしているのだと思います。
ということでしょうか。
品質のためのテスト、という意味では、個人的には「それで十
分」と感じるのですが、おおむらさんのおっしゃることも理解でき
る気がします。
仕様を記述すれば、それに基づいて自動的にテストができる。じ
つはそういうツールを作れないかと考えているところです。もとも
とは、受け入れテストを顧客役の人間が書くという要望から考え始
めました。テストケースのわかりやすさ・書きやすさを考えている
ので、おおむらさんの意図とは方向が違うと思いますが。
人間が記述する内容が「平日の9時から5時の間は手数料が￥０」
で済む。まあ、仕様を解析して、最終的なテストのロジックは特定
の値でやるしかありませんが。
じゃあ現実にツールでどこまでやれるのか？と考えると、とても
難しいわけですが (^^; たとえば、画面の入力チェックの仕様を
「引き落とし金額は正の整数で500,000以下」と書くだけで自動テ
ストしてくれる、というあたりが当面のスコープです。
> | また、XP(というかTDD)では、インターフェイスやクラスの構成
> |もテストドリブンで作っていけると思います(自分ではそうしてい
> |るつもりです)。
>
> それは、単にテストファーストだけでなく、リファクタリングも
> 含めた、より大きなスケールでのプロセスにおいて、の話のように
> 思いますが、違うでしょうか？
>
> インターフェイスやクラスの定義は、テストを書く前に決めて
> いないとテストが書けないので
> テストファーストだけでは、設計をすすめることはできないと思う
> のですが、テストドリブンだと、できるのでしょうか。
「テストファースト(テストドリブン)のコーディングでは、リ
ファクタリングは必須」です。リファクタリングにはクラス定義な
どを決めることも含みます。
リファクタリングをしないテストファーストもありますね。先に
クラス設計などをしてからそのとおりに実装する。この場合は「テ
ストファーストで設計を進める」ことにはなりません。これを「テ
ストドリブン」と呼ぶのはおかしいと感じますが。
# テストファーストとテストドリブンって同義語？
--
アジアパシフィックシステム総研 ソリューション３部 安井 力
http://www.asia.co.jp/ yasui@....jp
03-3985-3886 / FAX:03-3985-3778