矢崎です。
Ootaさんwrote:
>
> 従来の客観的にどの人が作っても同じように出来るテストケース(例えば、
> 同値分割 + 境界値分析)というのがありますよね。これだとどれだけテストを
> 行ったのかを不完全なりにも管理することが出来ます。逆にこのような基準が
> ないとテストは主観によるものとなってしまいます。XPのテストの例ですと主
> 観によるテストケースが多いように見えたので、この点がちょっと問題かな
> と。
>
> しかし、別に矢崎さんの仰るように客観によるテストケースを付け加えても
> かまわないわけですので、この点を補足すれば十分なのかもしれません。
>
私は、JUnitは単なるツールであって、それをどう使うかは、人間
側の課題だと思います。私としては、JUnitでテストをやって、それ
がある程度信頼を持てなければ、XPそのものを安心して適用でき
ないと思っています（リファクタリングして、テストして、その結果が
主観的でしかないとしたら、リファクタリングなんてできない！）。
なので、やはり、JUnitで行うとしてもテストの戦略が必要だと思い
ます。もし、その戦略を適用して、テストケースの数が多くなったと
してもです。。。
#２つの相反するフォース
・テストをささっと簡単に書いて、どんどん進捗を進めたい。
・信頼性の高いテストを書いて、確実に進捗させたい。
があったとしたら、ここでは、２つめのフォースをとります（＾＾）
#ただし、ブラックボックスレベルに限定して、でしょうか？ここは、
まだ迷いどころです。
>
> 私としては以前も書いたように、
>
> 1. まずテストを書く(ここは主観で良い、でも重要、ここが書けないというこ
> とはプログラムが何をすべきかを理解していないことになるから)
> 2. プログラムを書く
> 3. 1.のテストを100%通過させる
> 4. 同値分割 + 境界値分析もしくはホワイトボックス的な何らかのカバレージ
> 基準を採用し、この基準を満たすまでテストケースを追加する
> 5. 4.のテストを100%通過させる
>
そうですね。１で大体の仕様を明確にする。
２、３でごくごくシンプルなものを実現する。
４でよりちゃんと仕様にし、（だから、全てにおいて、ホワイトボックスをするか
どうかは、今は迷っています。）
５でより確かなものを作る。
というような感じでしょうか？
> 前半は「こう動いて欲しい」と「こう実装した」との間に生じるミスを検出
> するためのテスト、後半は「こう動いて欲しい」の予想からは想定していな
> かったような実装の誤りを検出するテストというのでしょうか。
>
御意！あるいは後半は、「より、ちゃんと仕様をつめる。。」nullがきたら
どうする？とか、、
>
> みたいなテストケースで十分だと思います(というのも怪しい)けど、内部的に
> は色々メンバがあってこの一貫性を記述するのがMeyerの表明であると考えて
> いますが。誤って理解しているのでしょうか。
>
私のほうがまちがって理解しているかもしれませんが、私は
Meyerの表明の考え方は、あくまでも仕様、外部、公開のもの
だと思っています。プライベートなメンバを触れるとしても、そ
れは、Eiffelが完全に形式化（数理論理学のように）されてい
ないための、いわば便法として使わざるを得ない状況がある、
というように考えています。翻訳本の２１１ページとかを読んで
そう解釈しているのですが、まちがっていますでしょうか？
--
矢崎博英 firo@....jp