早稲田大学の太田です。私のテストに関しての考え方はおおむらさんと矢崎
さんの認識の通りです。
おおむらさん
> たぶん、太田さんの危惧されているのは、XPを受け入れる我々が、無批判に
> UnitTestしたから万事OKと思い込むとまずいんじゃない？ っていうこと
> ですよね。
ええ、そうです。ISO 9000にしてもそうですが、どうも日本人はその背景に
ある本質を理解しないで、表面だけを取り入れてしまう傾向があるのでそれに
対する危惧です。
> は、「テストやってたんじゃだめだろ」という話だと思う
> のですが、それだけだと
> 「表明/契約」であろうが、UnitTestであろうが、テストを
> やる開発プロセス全部
> にあてはまる批判ですね。XPに特殊な条件はどこにあるの
> か把握できませんでした。
従来の客観的にどの人が作っても同じように出来るテストケース(例えば、
同値分割 + 境界値分析)というのがありますよね。これだとどれだけテストを
行ったのかを不完全なりにも管理することが出来ます。逆にこのような基準が
ないとテストは主観によるものとなってしまいます。XPのテストの例ですと主
観によるテストケースが多いように見えたので、この点がちょっと問題かな
と。
しかし、別に矢崎さんの仰るように客観によるテストケースを付け加えても
かまわないわけですので、この点を補足すれば十分なのかもしれません。
私としては以前も書いたように、
1. まずテストを書く(ここは主観で良い、でも重要、ここが書けないというこ
とはプログラムが何をすべきかを理解していないことになるから)
2. プログラムを書く
3. 1.のテストを100%通過させる
4. 同値分割 + 境界値分析もしくはホワイトボックス的な何らかのカバレージ
基準を採用し、この基準を満たすまでテストケースを追加する
5. 4.のテストを100%通過させる
というのが最も安心かなと思います(後半はペアの片方がやったほうが良い
ような気がします)。
前半は「こう動いて欲しい」と「こう実装した」との間に生じるミスを検出
するためのテスト、後半は「こう動いて欲しい」の予想からは想定していな
かったような実装の誤りを検出するテストというのでしょうか。
まあ、後半は例えば、
http://www.techmatrix.co.jp/asq/jtest
みたいな完全自動化ツールを使ってしまっても良いと思います(価格が・・
・)。
> というようなことはご存知であるような気もしますが、だとするとMyersは
> なにをそれにつけ加えたのでしょう？
ダイクストラは限界を示しただけですが、Myersはテストに関する新たな定
義「プログラムが正しいことを証明するのではなく、欠陥を想定しながら行う
行為である、欠陥を見つけてこそテストである」というのを打ちたてたという
ことではないでしょうか。
話題はそれますが、
平鍋さん
> > Meyerの表明
>
> > 内部から見た一貫性の保証
>
> > XPのUnit Test
>
> > 外部から見た一貫性の保証
>
> どちらも外部からの一貫性の保証では? そのコードが中にあるか，
> 外にあるか，の違いだと思いました．
Meyerの表明の場合、privateなメンバに関する制約も直接書けますよね。い
や、Javaではリフレクションを使えば書けなくもないですが。普通のXPのUnit
Testの場合、publicなメソッドを介した間接的なものではないかと。
Stackの例でしたら外部から見た場合、何もない状態でプッシュしてポップ
すると要素はゼロにもどるというシナリオを考えると
public void testStack() {
Stack anStack = new Stack();
Integer anInteger = new Integer(777);
assert(anStack.empty());
anStack.push(anInteger);
anStack.pop();
assert(anStack.empty());
}
みたいなテストケースで十分だと思います(というのも怪しい)けど、内部的に
は色々メンバがあってこの一貫性を記述するのがMeyerの表明であると考えて
いますが。誤って理解しているのでしょうか。
#JavaのAPIではStack自体はメンバを持っていなくてVectorから継承している
のですけど。
早稲田大学大学院理工学研究科情報科学専攻M2 太田健一郎
e-mail Address oota@....jp
oota@....jp