12/05/07 15:22:53.70
したでしょ
324:デフォルトの名無しさん
12/05/08 00:48:48.37
>>321
f(5)は5未満の偶数を1つ返すんだから0,2,4のいずれかだろ
これは極端な例だが
結果が一意に定まる一般的必然性はないだろ
325:デフォルトの名無しさん
12/05/08 10:38:13.91
うわこいつめんどくせぇ
326:デフォルトの名無しさん
12/05/08 11:12:23.01
>>324
そういう仕様だとしようか。
で、どこがテストしにくいの？
327:デフォルトの名無しさん
12/05/08 23:10:44.24
2や4がどの程度発生するべきかわからんね
return 0
なら仕様をみたすけど、本当にそれでいいの？使い物になるの？っていう
仕様の不透明な感じがイヤな臭いを放ってはいる
328:デフォルトの名無しさん
12/05/09 10:56:21.24
わからないことは、テストできませんね。不可能。
はい、次。
329:デフォルトの名無しさん
12/05/09 13:52:53.87
仕様が不明確だからテストできないというのは、このスレの対象外の話題です。
330:デフォルトの名無しさん
12/05/09 14:56:17.76
仕様が不明確な場合のテスト方法→仕様を明確にする
331:デフォルトの名無しさん
12/05/09 15:11:14.35
仕様が不明瞭だとテストのしようがありません
332:デフォルトの名無しさん
12/05/09 15:26:06.28
assertInArray([0, 2, 4], f(5));
で十分。
333:デフォルトの名無しさん
12/05/09 20:11:12.49
なんか見てると外延的なのが好きみたいね
内包的な記法の方が流行ってんのかと思った
内包的記法は強力すぎてバグの温床というのも
わからないでもないけど
334:デフォルトの名無しさん
12/05/10 10:31:38.45
強力すぎる内包的記法って、具体的にはどういうやつ？
なんで強力すぎるとバグの温床になるの？
335:デフォルトの名無しさん
12/05/10 12:48:15.35
内包でテストとかもはや何のテストしてるかわからんくなるな
336:デフォルトの名無しさん
12/05/10 21:03:39.02
>>313の例なら
内包的(implicit)
assert(isEven(f(5)) && f(5) < 5); みたいなの
外延的(explicit)
>>332みたいなの
内包的な記述の方がテスト対象に何を期待しているかを
分かりやすく「厳密に」記述できる
が、isEven()みたいに名前から実装が想像できる場合はともかく
複雑になってくると何をやっているか分らなくなる可能性はある
337:デフォルトの名無しさん
12/05/11 02:11:36.53
>>336
良く考えるんだ。
たとえば、引き数で指定したn個の数をすべて掛け合わせた結果を返す関数
f(x1. x2,…,xN)
を、内包でテスト書いてみ？
338:デフォルトの名無しさん
12/05/11 13:48:03.55
>>336
> 分かりやすく「厳密に」記述できる
うーん、
> assert(isEven(f(5)) && f(5) < 5);
より
> assertInArray([0, 2, 4], f(5));
の方がわかり易いし、厳密だと思うんだがなぁ。まぁ「厳密」の定義とかいう話はしたくないんだけど。
339:デフォルトの名無しさん
12/05/11 22:24:04.44
複雑だけど実行速度が速いアルゴリズムと
シンプルだけど遅いアルゴリズムがあったとき、
前者を実装したコードのテストに
後者を使う事はあるよ
340:デフォルトの名無しさん
12/05/12 00:22:42.63
>>337
良く考えるんだといわれても
assert(x1 * x2 * ... * xN==f(x1. x2,…,xN));
くらいじゃないのかね
それじゃテストにならないという意見を否定するつもりはないが
じゃあ他のテスト方法はあるの？
x1 * x2 * ... * xNをそろばんで計算した方が有意義とでも？
>>338
>>336には「テスト対象に何を期待しているか」と書いてある
assertInArray([0, 2, 4], f(5));
をパスして仕様に反するf()はいくらでも作れる
そういう意味での「厳密」
341:デフォルトの名無しさん
12/05/12 00:37:48.53
だからといって内包的なのが良いとか万能というつもりはない
少なくともテストにおいては
形式手法では話が変わる
342:uy
12/05/12 00:44:24.24
>>340
テスト対象のメソッドの中身と同じようなテストコードを書くか、
別のロジックを書き出すことになるか、
になってしまい
何のテストを書いているかわからんくなるのがオチだろう
テストはそろばんの方がいい
343:デフォルトの名無しさん
12/05/12 01:24:11.65
一般には適用できないが>>337の例なら
・引数のいずれかがゼロのとき結果がゼロになる
・1はいくらかけても1
・log(a*b*...)=log(a)+log(b)+...
とか数学的な性質を使った切り口がいいと思うけどね
内包的に書くにしても外延的に書くとしても
暗算するにしてもそろばんを使うにしても