安井@Aspacです。
はじめまして。横から参加させてください。
Shin wrote:
> つまり言いたかったのは、特定の値についてテストを書くとき、
> 実は、テストを書く人の頭の中には、もっと一般的だったり
> 抽象的な概念がうずまいていると思うのですよ。その世界は
> 無限の世界で、だから、実行することができないのだと
> 思います。
>
> それを、実行可能なテストにするために、そういう無限の世界から、
> 有限の世界におりてきて、特定の値のテストを書く。そういう
> ことをしているのだと思います。
実際にプログラムを書いているときには、抽象的な問題を取り扱
うことは少ないように感じます。逆に、取り扱う範囲をできるだけ
具体的に絞り込んでいけるように、設計しています。
たとえば、ATMの手数料を計算するときに「すべての日時に対し
て計算する」というものを、「曜日と時間帯に対して計算する」よ
うに具体的に落としていく方向で考えています。そしてテストでは、
・平日(たとえば月曜)、土曜、日曜
・料金の変わる時刻の前後
の組み合わせだけについて記述します。
これってホワイトボックステストの発想ですね。ですがホワイト
ボックスと考えると、これだけで完全な(＝すべての機能仕様を満
たした)テストになるんじゃないでしょうか。
>>仕様には明示的な仕様と暗黙的な仕様 (暗黙知に当たる部分と云うか)
>>が有って，暗黙的な方は文書化出来ないような気がしています．
>
>
> 確かにそうですね。
>
> 暗黙知の話とはずれますが、
> XPのプログラマはテストにすべてを書かないし書く必要はないと、考えら
> れているんじゃないかなと思います。
>
> 実はもっと仕様に書きこめる情報はあるのに、あえてテストにそれを
> 書かない、というような部分があるんじゃないでしょうか。
ここからわたしが連想するのは、非機能仕様についてのテストで
す。特にパフォーマンス。システム全体のパフォーマンスは、テス
トファーストで言うところのテストで確認するのは非現実的です。
しかしリファクタリングしているうちに徐々にパフォーマンスが劣
化する、ということはありえます。
異常系のテストも、テストケースだけで実現するのは難しい部分
があると思います。トランザクションがロールバックしたら、通信
が途中で切れたら、連携している外部システムが壊れたデータを
送ってきたら...というのは、異常の起きるパターンが無数にあり
えるので難しい。実際には可能性の低いところは排除してサンプリ
ングすることになりますが...
# 無数のパターンがあるから難しいのか、ブラックボックスだから
# 難しいのか。
> ちなみに、XPでは、インターフェイスやクラスの構成はユニットテスト
> 以前に決めてしまうから、その部分の仕様は当然、テストファーストの
> 範囲外ですね。
横道になっちゃうんですが、インターフェイスやクラスの構成っ
て仕様ですか？わたしは設計だと思います。ここで「設計」と言う
のは、仕様を実装に落とすために必要なモノの意味です。具体的に
イメージするのは、実装レベルのクラス図やシーケンス図、サンプ
ルのソースコード、複雑なロジックの実現方法の説明、などです。
また、XP(というかTDD)では、インターフェイスやクラスの構成
もテストドリブンで作っていけると思います(自分ではそうしてい
るつもりです)。
--
アジアパシフィックシステム総研 ソリューション３部 安井 力
http://www.asia.co.jp/ yasui@....jp
03-3985-3886 / FAX:03-3985-3778