太田です。
おおむらさん
>でももっと重要なことは、テストが常に特定の値に関する
>主張しかしていなくて、そのため、仕様というか、作ろう
>としているプログラムの論理的な構造が、テストファースト
>で作られたコードによって必ずしも実現されているとは
>いえない点です。
>テストにすべての仕様を盛り込むことは不可能だからです。
私もどちらかというとXPのテストよりも厳格なテスト(第三者検証より)の立場にあ
ります(これはXP-jpにはじめて参加したとき書きました)。
TDDでも
1. 重複を見つける
2. リファクタリングして抽象化する
3. 既存のテストを再実行する
4. すべてのテストを成功させる
とあるのですが，"1."から"2."への抽象化で実は一気に定義域と値域が広がる可能
性があるので，既存のテストケースではカバーできなくなるんですね。
例
int div(int a, int b) {
return 4 / 2;
}
int main() {
assert(2, div(4, 2));
}
でテストケース
assert(3, div(12, 4));
を追加して，TDDに従って，抽象化すると
int div(int a, int b) {
return a / b;
}
で追加したテストケースと既存のテストケースはパスするのですが，実際は b == 0
で落ちちゃいますよね("a / b"にしたことによって対象となる定義域の集合が一気に
int型すべてになりました)。
このレベルなら常識的にテストケースを増やせますが，もう少し難しくなったりする
と抽象化に対しテストケースのもれが確実に出てくるため，
「テストできるコードしか書いていない」
とは言えなくなります。
Kent Beckはこのようなテストの漏れは「経験によりカバーできる」と書いていま
すが，単体テストでのテストもれを防ぐためにはやはり既存のテスト手法，テスト方
法論も学んだ上でテストファーストを実践すべきなのかなと思います。
それとあちら(アメリカ，ヨーロッパ)では独立したテスト部門が存在することが多
く，ツールも充実しており，独自のノウハウが豊富に存在するためにプログラマのテ
ストファーストでカバーしきれない部分はそちらにお任せというシナリオもあるのか
なと。
#特に機能外要求の面など
基本から学ぶソフトウェアテスト―テストの「プロ」を目指す人のために
http://www.amazon.co.jp/exec/obidos/ASIN/4822281132/qid%3D1046393381/250-1112449-7573031
では，
「優れたプログラマはテスト担当者がテストする前にバグの99%をつぶしている。テ
スト担当者の仕事は残りの1%を見つけることだ」
みたいなことが書いてありました。
おおた oota_ken@....com
_________________________________________________________________
HP やメールアドレスを自分だけのオリジナルに MSN ドメイン
http://onamae.msn.co.jp/