オブジェクト指向システムの設計 170 [無断転載禁止]©5ch.io
■ このスレッドは過去ログ倉庫に格納されています
0001デフォルトの名無しさん
2016/05/30(月) 23:08:42.31ID:pIEuB3Z3オブジェクト指向は役割でオブジェクトに分割するものであって
処理で分割するものではない。
0153デフォルトの名無しさん
2016/06/02(木) 00:35:08.33ID:qX3K4vQy担当範囲がおかしいかどうかは議論するべき所じゃないよ。
問題が起きた時に誰に責任があるかの話なんかするつもりはない。
今話しているのは、こういう問題をどうやって解決するか
現実の話として、コードのコピペ等によって
仕様書から起こされたテスト項目では、バグがないことを担保できない場合がある。
（逆にコードが汎用化されていたりで、無駄なテストをしている場合もある）
バグがないことを担保するにはどうするか？
コードのレビューを行って、コードに問題がないことを
確認するしかないだろうね。
それをしないならば（つまり開発者の書いたコードを信用するならば）
コードにバグがないことを担保するためのテスト項目数は変わってしまう。
（ついでに言えば、どういうテストをすればいいかはコードを見ないとわからないので、やっぱりコードのレビューが必要）
0154デフォルトの名無しさん
2016/06/02(木) 00:37:15.86ID:IPFd2Mdrコードの条件がおかしい場合にテストで検知できるかって話。
要件にしたがってテストしていれば分かる。
要件にしたがってテストしたけどコードがアホ過ぎて検知できない場合もあるとしてもどうしようもない。
どうやって検知すんだ？って話。
0155デフォルトの名無しさん
2016/06/02(木) 00:40:13.45ID:IPFd2Mdrテスト漏れだとは思わない。
もちろんテスト項目として追加するなら追加して。
でも、テストが漏れていたとは思えない。
0156デフォルトの名無しさん
2016/06/02(木) 00:42:01.42ID:9SgsnltgどこにOOによる拡張性を持たせるかが問題になるから、要件とか設計からの要請で判断するべき。
Expression Problemで明確になることだけど、
OOPは子クラスを新たに追加するのは簡単な一方、新しいメソッドを追加するには既存のソースを変更しないといけない。
親クラスに共通の処理を書いたとしても、他と違うことをしたい子クラスの数だけ変更箇所が散らばる。
どの子クラスがオーバーライドしてるのかを把握するのに手間がかかるし、
追加するメソッドによってはクラス階層を更に分けてコピペを減らすべきかもしれない。
enumとswitchを使っている場合は逆になって、メソッドの追加や変更部分は一箇所にまとまっていて把握と追加が楽。
新しい種類のデータを追加するのは面倒。
ちなみにHaskellの型クラスやOCamlのvariant typeを使うとデータの種類も処理の種類も楽に増やせる。
Javaだとジェネリクスを使えばできないことはないけど、汚くなる。
0157デフォルトの名無しさん
2016/06/02(木) 00:42:37.96ID:qX3K4vQy> 要件にしたがってテストしたけどコードがアホ過ぎて検知できない場合もあるとしてもどうしようもない。
だからそのどうしようもないことが、現実として起きてるんだよ。
開発者の言う「このコードは汚い」というのはそういうこと。
コードの無駄やコピペがあって、本来十分であるはずのテスト項目では
バグがないことを担保できない。
言い換えると、コードに問題がある場合のバグは、仕様書から起こしたテストでは検出できない。
バグが検出できない（問題ないと判断される）のだから、当然コードの問題もテストでは検出できない
> どうやって検知すんだ？って話。
コードレビュー以外にも検知する方法はあるぞ。
コードメトリクス（複雑度）の測定や
コードの重複の検出ツールなどを使えば良い。
0158デフォルトの名無しさん
2016/06/02(木) 00:45:18.72ID:IPFd2Mdrコーダーがアホ過ぎたらそういうことも起きるって言ってるじゃん。
そこまでアホなコーダを想定してテストしろって要求するのはおかしいって話。
コーダーが犯すあらゆる過ち対応したテストを作成するのは不可能。
0159デフォルトの名無しさん
2016/06/02(木) 00:46:19.41ID:IPFd2Mdrツールがあるならコードを直そうね。
テストが漏れていると思うのはおかしい。
>コードレビュー以外にも検知する方法はあるぞ。
>コードメトリクス（複雑度）の測定や
>コードの重複の検出ツールなどを使えば良い。
0160デフォルトの名無しさん
2016/06/02(木) 00:48:15.80ID:55Jnw5v7関係無いよね
チェック項目は増えてない
仕様書から起こす入力に対する正しい出力をチェックするだけ
0161デフォルトの名無しさん
2016/06/02(木) 00:50:43.52ID:qX3K4vQy> コードレビューで問題が見つかったらコードを直すだけ。
> テスト漏れだとは思わない。
> もちろんテスト項目として追加するなら追加して。
> でも、テストが漏れていたとは思えない。
だからそういったじゃんｗ
正確にはテスト漏れじゃないが、開発者の書いたコードを素直に受け入れるならば、
コードによって問題がないことを担保するためのテスト項目は変わる。
コーディングによってテスト項目は変わるか？質問に対していうと、
「コードレビューで問題が見つかったらコードを直すだけ。」というならば
直さないならばテスト項目は変わるってことでしょう？
テスト項目を変えないためにコーディングを直すっていうのは、
テスト項目が変わる原因の一つがコーディングであると言ってるのと
微妙にニュアンスは違うけど、結果として殆ど変わらないよ。
0162デフォルトの名無しさん
2016/06/02(木) 00:53:04.14ID:qX3K4vQy> 仕様書から起こす入力に対する正しい出力をチェックするだけ
それはなんのためにやっているの？
テストはバグを検出するためにやっていると思ったが、
コードに問題があると、バグを検出できないってことだよね？
0163デフォルトの名無しさん
2016/06/02(木) 00:53:06.73ID:IPFd2Mdrコーディングによってテスト項目は変わるか？云々は知らない。
お前が言ってることがおかしいってだけ。
テスターは要件の境界線をテストする。
コードが異常な境界線を基準としていたためにバグを見逃していたとしてもテスターの責任ではない。
どうしようもない。
0164デフォルトの名無しさん
2016/06/02(木) 00:58:20.11ID:55Jnw5v7それも違う
境界なんてものは存在しない
本来は取り得る値すべてをチェックしなければならない
でも客とテスターの間の取引で暗黙に間引いてるってだけの話
0165デフォルトの名無しさん
2016/06/02(木) 00:59:05.09ID:qX3K4vQyだから責任問題の話なんかするつもり無いってばｗ
どんなコードであっても、同じテストをすれば
同じ品質（バグがない）を担保できるような話をしてるから、
同じテストをしたとしても（そのテストに漏れがなかったとしても）
コードにバグがないことを担保できないし、
コードの品質も同じにはならないよって話をしてるんだよ。
コードが悪ければ、品質を保つために必要なテスト項目は増えるし、
コードを直すことで、必要なテスト項目は減る。
（正確に言えば仕様書から起こした本来の最低限のテスト項目だけで済む）
0166デフォルトの名無しさん
2016/06/02(木) 01:01:46.10ID:IPFd2Mdr責任だけの話じゃない。対応のしようがないって話。
要件上引数は正の数でなければならないとする。
ところがコードがアホで引数が100だとバグが発生するとする。
テストではそれが分からなかった。
どうすんの？って話。
0167デフォルトの名無しさん
2016/06/02(木) 01:03:06.15ID:55Jnw5v7何度も言うけどソースコードからテスト項目は増えない
ソースからテスト仕様書作ってる会社なんてないだろうよｗ
0168デフォルトの名無しさん
2016/06/02(木) 01:07:07.95ID:T7FoO03YID:qX3K4vQy
ID:IPFd2Mdr
の主張がこんがらがってきた……
0169デフォルトの名無しさん
2016/06/02(木) 01:08:17.44ID:qX3K4vQyだからテストとは別にコードレビューをテスト前に行い、
悪いコードをあらかじめ直すしかないだろ？
俺が品質ベースで考えてるから話がずれてるのか？
俺はバグがないようにすることを目標として
どんなテストが必要か？を考えてる。
だからバグを無くすためには、コードによって必要なテスト項目が変わってくる。
そしてコードを良くすることで、必要なテスト項目が減るという話をしてるんだよ。
仕様書からテストを起こすっていうのは、当然コードは見てないから
必要な（最低限の）テストは何か？だけを考えてる。
テストの効果（バグを見落とすかどうか）は考えておらず、
その効果はコードによってばらばらで、テストしてもバグを検出できるとは限らない。
この場合のテストの目的は何なんだろうかねｗ
0170デフォルトの名無しさん
2016/06/02(木) 01:08:59.38ID:IPFd2Mdrうん。だからコードを直そうね。
テスト漏れじゃないね。
0171デフォルトの名無しさん
2016/06/02(木) 01:12:05.80ID:qX3K4vQy> 何度も言うけどソースコードからテスト項目は増えない
それはテストの効果（バグがないことの担保）
を無視すればそうなるよね。
ソースコードからテスト項目は増えないが
ソースコードが悪ければ、その増えないテスト項目では
バグを見逃す可能性が高くなる。
テストの効果を低くしていいならば、
テスト項目は増やさなくていいよ。
そしてソースコードが汚いならばソースコードの方を直すんだろう？
なぜなら、ソースコードが汚ければテスト項目を
増やさなければならなくなるから（アレ？ｗ）
0172デフォルトの名無しさん
2016/06/02(木) 01:12:26.96ID:T7FoO03YID:qX3K4vQyの主張はコードからテストケース作る
ID:IPFd2Mdrの主張は設計書からテストケース作る
コードが設計書に書かれてることを満たしてるかどうかって
コードから作ってたらわからないのでは……って疑問が……
なぜかコードだけ、設計書だけの0か100かに見えてしまってるので
勘違いしてたらごめん
0173デフォルトの名無しさん
2016/06/02(木) 01:13:23.53ID:qX3K4vQy> うん。だからコードを直そうね。
> テスト漏れじゃないね。
コードを直さないとどうなる？
同じ品質を保つにはテストを増やす必要があるよね？
えーと、それがコーディングによってテスト項目は
変わるってことだよねｗ
コーディングによってテスト項目が増えるから
コーディングを直すんだよね？ｗ
0174デフォルトの名無しさん
2016/06/02(木) 01:14:50.74ID:55Jnw5v7どうにでも好きなように組んだらいいよ
チェック項目は変わらない
オブジェクト指向でも関数型でも
これが設計の本質だ
単にソースコードに書く場所が違うだけ
それがオブジェクト指向
こんなもんにマジになっちゃってどうするの?
っていうIT業界の黒歴史
0175デフォルトの名無しさん
2016/06/02(木) 01:16:20.73ID:IPFd2Mdr>>166
そりゃバグがあることが判明したらテストを追加すべきだろうね。
でも、そもそもテストが不足していたということじゃないね。
0176デフォルトの名無しさん
2016/06/02(木) 01:18:59.63ID:qX3K4vQy俺の意見としては、テストとは別にコードレビューが必須であるということ。
仕様書からテストをおこすのは問題ないんだが、
そのテストで品質が保てるかどうかは
コードで左右される。
コードが汚ければいくらまともなテスト行ったとしても
それで品質を保つことは出来ない。
俺は品質を保つことを第一に考えてるので
コードを直さずに品質を保つならばテスト項目が増えてしまうという話をしてる。
だからテスト項目を増やさずに品質を保つために、コードを直しましょうという話をしている。
で、最初の疑問「コーディングによってテスト項目は変わるか？」の
答えは、（品質を保つことを前提にすると）コーディングによってテスト項目は変わる。
悪いコードだと（品質を保つために）テスト項目が増えてしまう。だからコーディングを直しましょう。
0177デフォルトの名無しさん
2016/06/02(木) 01:21:24.41ID:IPFd2Mdrコードレビューで仕様の境界とは違うところで問題が見つかったらコードを直すだけ。
そんなのテスト作成とは関係ない。
0178デフォルトの名無しさん
2016/06/02(木) 01:23:15.23ID:qX3K4vQy> そりゃバグがあることが判明したらテストを追加すべきだろうね。
リリースした後で、バグが有りました。すいません。ですむ会社なら
それでもいいけどさぁｗ
「ちゃんとテストしたの？」の答えに
テストは不足していません！ちゃんとテストしました！
ちゃんとテストしたのに、コードが悪かったんです！
ですむなら、それでもいいけどさぁｗ
理想の世界であれば、テストが不足してないのは事実だろうが、
そのテストで十分であるためには、コードが綺麗でなければならず、
コードが汚ければ、多くのテストが必要になるから
コードレビューをして綺麗なコードにしましょうや。
それができて初めて、テストする意味が生まれる。
0179デフォルトの名無しさん
2016/06/02(木) 01:24:18.99ID:qX3K4vQy> コードレビューで仕様の境界とは違うところで問題が見つかったらコードを直すだけ。
だから何度もそう言ってるだろうが。
人の話聞けよｗ
0180デフォルトの名無しさん
2016/06/02(木) 01:24:53.24ID:IPFd2Mdrだからさ、要件の境界とは違うところでコードがアホ過ぎるせいでバグがあったとして見つける手段は？
見つける手段がないのに直そうと言っても意味ない。
0181デフォルトの名無しさん
2016/06/02(木) 01:25:55.40ID:IPFd2Mdr？？
だったらいちいち反論すんなよ。
0182デフォルトの名無しさん
2016/06/02(木) 01:26:39.31ID:qX3K4vQy品質を保つことを前提にするならば、
コードが汚ければ、品質を保つために必要なテストが増えてしまうから、
まずコードレビューしてコードを綺麗にしましょうって話。
コードが綺麗な状態であって初めて、仕様書から起こしたテストで十分だと言える。
0183デフォルトの名無しさん
2016/06/02(木) 01:29:14.56ID:qX3K4vQy> だったらいちいち反論すんなよ。
お前が反論してるんだろｗ
っていうかお前のは反論じゃない。
俺が言っていることと違うことをぶつけているだけ。
俺が言ってるのは、コードが汚いならば（品質を保つために）
必要なテストは増えるって話。
コードが汚くても、テストは増やさないで品質が保てるような
話をしているから、その発想は抜けがあるよってこと。
0184デフォルトの名無しさん
2016/06/02(木) 01:29:26.96ID:soSMk704コード改変の前後でエンバグしたかどうかがすぐわかります
なおユニットテストそのものの品質を保つかが課題
0185デフォルトの名無しさん
2016/06/02(木) 01:30:23.03ID:T7FoO03Y了解
回答ありがとう
0186デフォルトの名無しさん
2016/06/02(木) 01:30:30.71ID:qX3K4vQy> 見つける手段は？
それもテスト前にコードレビューするって何度も言ったはずだが？
汚いコードは直さないと、テストした所で効果は低い
0187デフォルトの名無しさん
2016/06/02(木) 01:31:11.16ID:IPFd2Mdr本来的にはテストは要件にしたがって動作することを確認するためのもの。
コードがきれいか汚いかとか関係ない。
0188デフォルトの名無しさん
2016/06/02(木) 01:32:06.67ID:IPFd2Mdrコードレビューで見つかったなら直せ。以上。
テストとの直接の関係はない。
0189デフォルトの名無しさん
2016/06/02(木) 01:33:09.51ID:qX3K4vQy> 本来的にはテストは要件にしたがって動作することを確認するためのもの。
その確認の手間がコードによって変わってしまうんだよ。
すでにコードで例示したけど？
0190デフォルトの名無しさん
2016/06/02(木) 01:33:30.12ID:dD1ozz1qコンパイルできた時点でバグが無いことが保証されるから。
0191デフォルトの名無しさん
2016/06/02(木) 01:34:23.43ID:IPFd2Mdrコードがアホなだけ。テストではどうしようもない。
と結論が出てる。
0192デフォルトの名無しさん
2016/06/02(木) 01:34:39.66ID:55Jnw5v7だから変わらないって
本来は取りうる値の範囲をすべてチェックするんだから
0193デフォルトの名無しさん
2016/06/02(木) 01:34:52.13ID:qX3K4vQy「直接の関係はない」ってことは
やっぱり間接的に関係があるって認めるんだｗ
そりゃコードによって品質を保つための
テストは変わりますからねｗ
バグが有るかどうか知ったこっちゃない。
俺はテストをちゃんとやった。
テストしたのに漏れたのはコードが悪いんだ！
ですむなら良い世界だねｗ
0194デフォルトの名無しさん
2016/06/02(木) 01:35:31.60ID:55Jnw5v70195デフォルトの名無しさん
2016/06/02(木) 01:36:12.80ID:IPFd2Mdrコードレビューで問題が見つかったらテストケースを追加してもいいよねってだけ。
0196デフォルトの名無しさん
2016/06/02(木) 01:36:59.90ID:dD1ozz1qHaskell以外淘汰されます。
0197デフォルトの名無しさん
2016/06/02(木) 01:37:36.91ID:IPFd2MdrHaskellとか既に淘汰されてるんだが。
0198デフォルトの名無しさん
2016/06/02(木) 01:38:47.83ID:qX3K4vQy> 本来は取りうる値の範囲をすべてチェックするんだから
うん、ネタなのは分かってるよ（笑）
分かってて聞くけど、ある数値を二乗する関数があったとして
Rubyで取りうる値の範囲はどうなるかい？
なんでRubyと言ったかというと、RubyではIntの範囲を超えると
自動的にBignumに拡張されるからとても大きな整数を扱えるんだぜ！
0199デフォルトの名無しさん
2016/06/02(木) 01:39:44.45ID:qX3K4vQy> コードレビューで問題が見つかったらテストケースを追加してもいいよねってだけ。
誰がやんの？ テスターのお仕事？
0200デフォルトの名無しさん
2016/06/02(木) 01:40:36.22ID:IPFd2Mdrコードレビューって自分で言ったんだから知ってるだろ。
分かってることをいちいち聞くな。
0201デフォルトの名無しさん
2016/06/02(木) 01:40:47.43ID:dD1ozz1q0202デフォルトの名無しさん
2016/06/02(木) 01:42:30.76ID:55Jnw5v7コードの記述方法でチェック項目は変わらない
つまりオブジェクト指向でも関数型でも品質は上がらない
言い換えればコードの記述方法で品質は上がらない
品質を上げるにはしっかり仕様書を書いて
しっかり書いた仕様書からテスト仕様書を起こすこと
ソースの記述方法は品質を決定する計算式に入ってません（笑）
おｋ?
0203デフォルトの名無しさん
2016/06/02(木) 01:43:13.49ID:qX3K4vQyせやね。
コードが悪ければコードレビューで
テスト項目が追加される。
コードが悪ければ、テスト項目が追加される。
おや？
コーディングによってテスト項目が変わるって話に戻ったか。
0204デフォルトの名無しさん
2016/06/02(木) 01:44:21.91ID:IPFd2Mdr「追加してもいい」
この意味が分からんの？
日本語からやり直せ。
0205デフォルトの名無しさん
2016/06/02(木) 01:46:16.79ID:55Jnw5v70206デフォルトの名無しさん
2016/06/02(木) 01:46:33.24ID:IPFd2Mdr基地外
0207デフォルトの名無しさん
2016/06/02(木) 01:47:36.18ID:3RkkmY6H>>140
> どう組んでもチェック項目は絶対同じ数と内容になる
そうでもないというか、その発想は抜けがあるよ。
たとえば数値が偶数か奇数かを文字列で返す関数があったとしよう。
function foo(value) {
return (value % 2 == 0) ? 'even' : odd';
}
これのチェック項目はfoo(0)とfoo(1)の2つで十分だろう。
だけどさ、関数の中身がこうなっていたらどうする？
（1レスに収めるためにわざと改行せずに一行にしたけどそこは無視して）
function foo(value) {
var i = value % 10;
if (i == 0) return 'even'; if (i == 1) return 'odd';
if (i == 2) return 'even'; if (i == 3) return 'odd';
if (i == 4) return 'even'; if (i == 5) return 'odd';
if (i == 6) return 'odd'; if (i == 7) return 'odd';
if (i == 8) return 'even'; if (i == 9) return 'odd';
}
わざとバグを入れたけど、バグが無ければこの関数は仕様どおりに動くしfoo(0)とfoo(1)のテストにも通る。
だけどこの関数にはバグがあるし、だからチェック項目は2つでは十分ではないということになる。
コーディングの仕方でチェック項目数は変わらないっていうのは、半分は正しい。
もし2つあるコードのどちらも同じぐらい正しい品質であればその通り。
だけどこの例の場合は違う。2つのテストでは足りないということになっている。
この例のあるべき姿はチェック項目数を増やすのではなくて、コードをリファクタリングしてシンプルにすること。
そうすることでチェック項目は2つになるわけだが、ここまでの話で明らかなように
「コーディングの仕方でテスト項目は変わる」というか「悪いコードだとバグがないことを担保するためのテスト項目は増える」
0208デフォルトの名無しさん
2016/06/02(木) 01:49:05.94ID:3RkkmY6H0209デフォルトの名無しさん
2016/06/02(木) 01:50:22.82ID:55Jnw5v7だからvalの取りうる範囲チェックするだろ
中間値だけとか間引くのはテスターが勝手にやってるだけの話
チェック項目は変わらない
0210デフォルトの名無しさん
2016/06/02(木) 01:51:43.92ID:3RkkmY6Hだから、そのvalの取りうる値ってなんだよ？ｗ
>>198の質問にも答えてないぞお前ｗ
0211デフォルトの名無しさん
2016/06/02(木) 01:53:10.76ID:ehI/NdEG完全に横だが、、、
そちらの意見自体に文句はない。つまり、コード品質最優先で同意だ。
付け加えるとしたら、>>143の例ならカバレッジで確認できる。
つまりC1(方言かもしれんが各分岐）まで含めれば例示されたバグは落とせる。
あと、仕様から起こしたテストを一通りやらないと「実装忘れ」を検出できない。
例えば、関数電卓を作ったとして、色々ある関数の一つを実装し忘れたとか。
実装漏れをテストではなくコードレビューで落とすことは出来るが、これはポリシーの問題となる。
仕様から起こしたテストで品質が上がるかというと、多分無理だ。これは競合を落とせない。
各競合を全部コードレビュー時にテストに追加するという手もあるが、これは追加漏れが発生する。
だから品質を上げるためには結局ランダムテストしかないと俺は思っている。
0212デフォルトの名無しさん
2016/06/02(木) 01:55:40.16ID:55Jnw5v7仕様書に書いてあるだろ?
ないの?
そしたら不具合ですらないんじゃない?
0213デフォルトの名無しさん
2016/06/02(木) 02:01:57.34ID:IPFd2Mdrカバーできてないことが判明
コードを直す
テストを追加するかは任意
0214デフォルトの名無しさん
2016/06/02(木) 02:03:26.51ID:IPFd2Mdrランダムテストって謎。
ランダムテストでアホなコードが漏れたらって話だろ。
なんでランダムテストさえすればアホなコードがすべて網羅できるって前提なんだよ？
0215デフォルトの名無しさん
2016/06/02(木) 02:25:10.08ID:ehI/NdEGいや、複数箇所に冗長に記述があった時、それらが整合しているかだろ？
見た瞬間分かればいいけど、クラスをまたいでいたりすると単純には削除できないケースもある。
この場合はカバレッジ100%なら整合している可能性が高い事は言える。
（ただし二重に冗長な場合は無理だが）
ランダムテストは動作の確認とカバレッジを稼ぐため。つまりバグの検出。
ランダムテスト自体では「品質の高い＝美しいコード」は得られない。
ただ、コードの品質って大前提として「バグがないこと」だろ？(コードが美しいことではなくて)
これについてはランダムテストが一番だと思っている。
すまんがもう寝る。
0216デフォルトの名無しさん
2016/06/02(木) 03:00:45.20ID:dD1ozz1q0217デフォルトの名無しさん
2016/06/02(木) 04:13:03.69ID:soSMk704あとは重箱の隅をつつく価値があるかどうか
0218デフォルトの名無しさん
2016/06/02(木) 04:24:49.52ID:dD1ozz1qテストでバグを発見できるというのは甘え。
0219デフォルトの名無しさん
2016/06/02(木) 06:09:23.71ID:a5hqyyy7Haskellを使っていれば交通事故を起こさない自動車だって作れた
なお完成は２４世紀ごろを予定しております
0220デフォルトの名無しさん
2016/06/02(木) 06:54:53.87ID:ehI/NdEG(モデルを作成し、ランダムな入力を食わせて出力をチェックする）
混乱させてすまん。
0221デフォルトの名無しさん
2016/06/02(木) 08:36:32.58ID:jj0I32l4＞たとえば数値が偶数か奇数かを文字列で返す関数があったとしよう。
＞これのチェック項目はfoo(0)とfoo(1)の2つで十分だろう。
充分じゃない、テスト仕様書がそうなってたらテスト仕様書書いた奴氏ねって言っていい、コードがどうなっているかはこの時点では関係ない
0222デフォルトの名無しさん
2016/06/02(木) 09:21:14.08ID:qVro3+K+あんたHaskell信者に見せかけたアンチだろｗ
HaskellにはHaskellの良さがあるけど、俺は結局C++に戻ってきた。
最近はCまで戻ろうかと検討してる。
もしくはLispを試してみようかなと。
0223デフォルトの名無しさん
2016/06/02(木) 09:59:19.16ID:9Sgsnltgコードから書けるテストはホワイトボックステスト。
ブラックボックステストで全ての取りうる値を入力するなんて非現実的だから、境界条件を考慮してテストセットを作る。
ホワイトボックステストはどれだけ網羅するかにもよるけど、条件分岐があったらその全てを通るテストセットを作る。
テストで得られる保証の度合いで言うならホワイトボックス>ブラックボックスなのは確かだけど、
中身まで見れる状態になっていないとホワイトボックステストは書けない。
開発プロセスがトップダウン方式だったりテスト駆動開発だと、書けるテストはブラックボックステストにならざるを得ない、という現実的な話。
そこで満足するか、更なる品質保証のためのホワイトボックステストを書くかはコストと相談しましょう。
Haskellでも同じ。テストを書く必要が無いのは依存型やRefinment typesを使える言語だけ。
0224デフォルトの名無しさん
2016/06/02(木) 10:42:12.02ID:x8NBN55x> コードが綺麗な状態であって初めて、仕様書から起こしたテストで十分だと言える。
その仕様書とやらが、コードをC0カバレッジできるレベルで書かれてるならそうだろうな。
0225デフォルトの名無しさん
2016/06/02(木) 10:43:30.50ID:x8NBN55x> すまぬ。「ランダムテスト」は方言で、標準語ではどうやら「自動テスト」と呼ばれるようだ。
いや、呼ばれない。自動テストとはマニュアルテストの反語。
0226デフォルトの名無しさん
2016/06/02(木) 10:58:37.56ID:HMnON+AyQuickCheckって呼んでるわ
0227デフォルトの名無しさん
2016/06/02(木) 10:59:58.45ID:qVro3+K+data-driven testing toolと呼ぶらしい。
0228デフォルトの名無しさん
2016/06/02(木) 11:24:00.72ID:tJT0ttjQある条件判定がfalseになったんだけど
それが正しいか間違ってるかってどうやって判定すんの?
ソースコードだけにその答えがあるの?
0229デフォルトの名無しさん
2016/06/02(木) 11:30:53.69ID:x8NBN55x> ある条件判定がfalseになったんだけど
> それが正しいか間違ってるかってどうやって判定すんの?
もっと具体的に。
0230デフォルトの名無しさん
2016/06/02(木) 12:11:08.77ID:tJT0ttjQif（val==false）
0231デフォルトの名無しさん
2016/06/02(木) 12:34:31.31ID:j1kGed0yさんさんと照り付ける太陽がS2715Hに映り込む。
純度100%のグレアモニター、S2715Hに自分の影がシャープに映り込むと、一日が始まる。
見ているものが正確で、映っているものは色が正確で、光量も正確。
よい生活はよい製品から得られる。
0232デフォルトの名無しさん
2016/06/02(木) 12:46:55.06ID:x8NBN55xそれは一体どこの話なんだ？
そもそも、（単体/unit）テストが何なのか理解してるか？
0233デフォルトの名無しさん
2016/06/02(木) 12:48:55.39ID:tJT0ttjQunkoクラスのgetPPメソッド
0234デフォルトの名無しさん
2016/06/02(木) 12:50:25.29ID:soSMk7040235デフォルトの名無しさん
2016/06/02(木) 12:54:33.11ID:x8NBN55xということであれば、単体/unitテストでは、正しいも間違っているも判定しない。
0236デフォルトの名無しさん
2016/06/02(木) 14:26:28.50ID:fuTkOmr9無駄なことに時間を費やしたくない人は
OOPが得意な部分だけを上手に利用することだけを考えておけばよい
ほとんどの実用的な言語がマルチパラダイムを選択していることからもわかる通り
当たり前に得手不得手があるし
一つの考え方だけでうまくいくほど世の中単純ではないことは子供以外は誰でも知っている
0237デフォルトの名無しさん
2016/06/02(木) 16:51:41.22ID:9Sgsnltgコードだけ見て判断できるものもあるし、仕様書読まないと判断できないものもあるとしか言えない。
どっちを参照しても分からないなら作った人に聞くべきだけど、それはテストじゃなくてレビューになる。
それとも仕様書無しでソースあり、さあテストを書けって場合を考えている？
そんな苦役を振られたら、仕様書を作って欲しいのか確実に動かないバグを潰して欲しいのか確認するところから始めましょう。
0238デフォルトの名無しさん
2016/06/02(木) 18:22:00.20ID:55Jnw5v7いや、オブジェクト指向だとテストが減るとか言ってるアホがいたから
0239デフォルトの名無しさん
2016/06/02(木) 19:13:46.82ID:IPFd2Mdrオブジェクト指向の目的聞かれて回答しないままトンずらした奴だろ。
0240デフォルトの名無しさん
2016/06/02(木) 22:51:27.39ID:3RkkmY6H> 仕様書に書いてあるだろ?
仕様書には「整数」って書いてあるけど、
そしたら、無限にある整数を全部テストしろって話でしょう？ｗ
0241デフォルトの名無しさん
2016/06/02(木) 23:08:39.30ID:soSMk704複雑になるとUndecidableなのが玉に瑕
0242デフォルトの名無しさん
2016/06/02(木) 23:26:10.98ID:55Jnw5v7駄目な仕様書だな
上限も下限も定義されてないでモノなんて作れっかよ
全く仕事やってない証拠
オブジェクト指向なんかどうでもいいから
設計書きっちり書けよって話
0243デフォルトの名無しさん
2016/06/02(木) 23:37:42.96ID:3RkkmY6H> 駄目な仕様書だな
> 上限も下限も定義されてないでモノなんて作れっかよ
作れるだろ？Pythonは無限リストを作れるのが特徴だ。
無限リストには上限も下限もない。
0244デフォルトの名無しさん
2016/06/02(木) 23:40:01.75ID:3RkkmY6Hhttp://docs.ruby-lang.org/ja/2.2.0/class/Bignum.html
あえて言えばメモリサイズによる制限は受けるが、
じゃあメモリサイズいっぱいの桁数の数値（何桁だと思う？ｗ）を
全部テストするのかとｗ
0245デフォルトの名無しさん
2016/06/02(木) 23:58:48.20ID:fuTkOmr90246デフォルトの名無しさん
2016/06/03(金) 00:01:57.95ID:57ESL53T仕方ないんじゃないかな？
馬鹿なんだからそういういちゃもんを付けるしかないんだと思うよ。
0247デフォルトの名無しさん
2016/06/03(金) 00:04:49.79ID:fpUAqgyP組合せ爆発でも起こしたら、本当に何万年とか
かかってしまうのがテストなんだよね。
仕様書に上限や下限をつけた所でなんの対策にもなっていない。
0248デフォルトの名無しさん
2016/06/03(金) 00:08:30.87ID:LbxBbQld下限も上限も決まってなかったら本当にテストできない
下限も上限も決めないのは馬鹿
0249デフォルトの名無しさん
2016/06/03(金) 00:24:19.96ID:4VbjelCP上限や下限が出てきたのは「整数」ではだめって文脈からだろ。
整数に上限や下限をつけた所でその範囲のすべての整数の
数は膨大なのだからテストに何万年もかかる。
そういう話をしてるのよ？わかる？
0250デフォルトの名無しさん
2016/06/03(金) 00:34:26.00ID:LbxBbQldそりゃ君はクライアントに無限大を約束するらしいから無限のテストが必要なのかもしれないが
それは君だけの話であって
我々は上限を設けて、その範囲内でだけ動くことを約束するって言ってるんだから
閾値のチェックだけで済むわけだ
0251デフォルトの名無しさん
2016/06/03(金) 00:42:42.22ID:xWVfr+QLまったく意味がない話になってるからテストの話はいい加減にしろ。
オブジェクト指向設計と関係ないし。
0252デフォルトの名無しさん
2016/06/03(金) 00:55:16.41ID:4VbjelCP上限下限がないならば、閾値の内側だけを調べればいいんだよ。
■ このスレッドは過去ログ倉庫に格納されています