オブジェクト指向システムの設計 170

1 名前：デフォルトの名無しさん mailto:sage [2016/05/30(月) 23:08:42.31 ID:pIEuB3Z3.net] オブジェクト指向に限らず、理由もなく小さく細分化させるのはアホ オブジェクト指向は役割でオブジェクトに分割するものであって 処理で分割するものではない。 152 名前：デフォルトの名無しさん mailto:sage [2016/06/02(木) 00:23:27.91 ID:qX3K4vQy.net] >>144 逆に無駄なテストっていうのもある。 たとえば、入力画面に数値入力項目が複数ある。 たとえば「原価」「定価価格」「値引価格」みたいに。 で仕様書では、それぞれの入力項目は数字しか入力できないこと。 という仕様だったとする。 このテストに「原価」「定価価格」「値引価格」の三箇所を それぞれ数字しか入力できないことをチェックするのか？ということ。 同じ画面ならば省こうと思うかもしれないが、 これが違う画面にある「年齢」だったらどうするか？ 仕様書から起こせば、それぞれの項目でチェックしようってなりそうだろう？ だけど開発者がこれらを、数値入力項目用の汎用コンポーネントで実装すれば 数字しか入力できないというテストは無駄でしかない。 ・・・が、開発者が馬鹿で、一箇所だけ普通の入力項目を使って 独自で数字のみ有効なんてコードを書いていたら？ 153 名前：デフォルトの名無しさん mailto:sage [2016/06/02(木) 00:27:08.04 ID:IPFd2Mdr.net] >>149 テストスクリプトとしては数字以外が入力されたらエラー処理がなされることを確認する以外の対応がむしろないな。 154 名前：デフォルトの名無しさん mailto:sage [2016/06/02(木) 00:27:39.75 ID:qX3K4vQy.net] >>147 > これあるいはこのようなバグによりテストができていないことが判明した場合、 いや、だからテストは通ったって書いたじゃんｗ テストは通るけど、バグがある場合があるんだよ。 そして、テスト仕様書自体は正しく、コードが間違っている。 だから正確に言えばコードによってチェック項目が変わるのではなくて、 そのチェック項目では、コードに問題がないことを担保できない。 チェック項目が十分かつコードにも問題がないことを担保するには あらかじめコードのチェックが必要って話。 もし「コードの方を直さない」ならば、コーディングによって 問題がないことを担保するための、チェック項目は変わってしまう。 155 名前：デフォルトの名無しさん mailto:sage [2016/06/02(木) 00:31:00.69 ID:IPFd2Mdr.net] >>151 概念的にはテスターとコーダーは違う人。 テスターは仕様の境界でテストするのであって、コードの境界でテストすることをようきゅうするのはおかしい。 テスターとコーダーが同一人物であったとしたらコーダーがアホだとテストが漏れるのはどうしようもない。 156 名前：デフォルトの名無しさん mailto:sage [2016/06/02(木) 00:35:08.33 ID:qX3K4vQy.net] >>152 担当範囲がおかしいかどうかは議論するべき所じゃないよ。 問題が起きた時に誰に責任があるかの話なんかするつもりはない。 今話しているのは、こういう問題をどうやって解決するか 現実の話として、コードのコピペ等によって 仕様書から起こされたテスト項目では、バグがないことを担保できない場合がある。 （逆にコードが汎用化されていたりで、無駄なテストをしている場合もある） バグがないことを担保するにはどうするか？ コードのレビューを行って、コードに問題がないことを 確認するしかないだろうね。 それをしないならば（つまり開発者の書いたコードを信用するならば） コードにバグがないことを担保するためのテスト項目数は変わってしまう。 （ついでに言えば、どういうテストをすればいいかはコードを見ないとわからないので、やっぱりコードのレビューが必要） 157 名前：デフォルトの名無しさん mailto:sage [2016/06/02(木) 00:37:15.86 ID:IPFd2Mdr.net] >>153 コードの条件がおかしい場合にテストで検知できるかって話。 要件にしたがってテストしていれば分かる。 要件にしたがってテストしたけどコードがアホ過ぎて検知できない場合もあるとしてもどうしようもない。 どうやって検知すんだ？って話。 158 名前：デフォルトの名無しさん mailto:sage [2016/06/02(木) 00:40:13.45 ID:IPFd2Mdr.net] コードレビューで問題が見つかったらコードを直すだけ。 テスト漏れだとは思わない。 もちろんテスト項目として追加するなら追加して。 でも、テストが漏れていたとは思えない。 159 名前：デフォルトの名無しさん mailto:sage [2016/06/02(木) 00:42:01.42 ID:9Sgsnltg.net] 後で拡張することが無い部分をswitchで書くのは全然問題無いと思うが。 どこにOOによる拡張性を持たせるかが問題になるから、要件とか設計からの要請で判断するべき。 Expression Problemで明確になることだけど、 OOPは子クラスを新たに追加するのは簡単な一方、新しいメソッドを追加するには既存のソースを変更しないといけない。 親クラスに共通の処理を書いたとしても、他と違うことをしたい子クラスの数だけ変更箇所が散らばる。 どの子クラスがオーバーライドしてるのかを把握するのに手間がかかるし、 追加するメソッドによってはクラス階層を更に分けてコピペを減らすべきかもしれない。 enumとswitchを使っている場合は逆になって、メソッドの追加や変更部分は一箇所にまとまっていて把握と追加が楽。 新しい種類のデータを追加するのは面倒。 ちなみにHaskellの型クラスやOCamlのvariant typeを使うとデータの種類も処理の種類も楽に増やせる。 Javaだとジェネリクスを使えばできないことはないけど、汚くなる。 160 名前：デフォルトの名無しさん mailto:sage [2016/06/02(木) 00:42:37.96 ID:qX3K4vQy.net] >>154 > 要件にしたがってテストしたけどコードがアホ過ぎて検知できない場合もあるとしてもどうしようもない。 だからそのどうしようもないことが、現実として起きてるんだよ。 開発者の言う「このコードは汚い」というのはそういうこと。 コードの無駄やコピペがあって、本来十分であるはずのテスト項目では バグがないことを担保できない。 言い換えると、コードに問題がある場合のバグは、仕様書から起こしたテストでは検出できない。 バグが検出できない（問題ないと判断される）のだから、当然コードの問題もテストでは検出できない > どうやって検知すんだ？って話。 コードレビュー以外にも検知する方法はあるぞ。 コードメトリクス（複雑度）の測定や コードの重複の検出ツールなどを使えば良い。 161 名前：デフォルトの名無しさん mailto:sage [2016/06/02(木) 00:45:18.72 ID:IPFd2Mdr.net] >>157 コーダーがアホ過ぎたらそういうことも起きるって言ってるじゃん。 そこまでアホなコーダを想定してテストしろって要求するのはおかしいって話。 コーダーが犯すあらゆる過ち対応したテストを作成するのは不可能。 162 名前：デフォルトの名無しさん mailto:sage [2016/06/02(木) 00:46:19.41 ID:IPFd2Mdr.net] >>157 ツールがあるならコードを直そうね。 テストが漏れていると思うのはおかしい。 >コードレビュー以外にも検知する方法はあるぞ。 >コードメトリクス（複雑度）の測定や >コードの重複の検出ツールなどを使えば良い。 163 名前：デフォルトの名無しさん mailto:sage [2016/06/02(木) 00:48:15.80 ID:55Jnw5v7.net] >>143 関係無いよね チェック項目は増えてない 仕様書から起こす入力に対する正しい出力をチェックするだけ 164 名前：デフォルトの名無しさん mailto:sage [2016/06/02(木) 00:50:43.52 ID:qX3K4vQy.net] >>155 > コードレビューで問題が見つかったらコードを直すだけ。 > テスト漏れだとは思わない。 > もちろんテスト項目として追加するなら追加して。 > でも、テストが漏れていたとは思えない。 だからそういったじゃんｗ 正確にはテスト漏れじゃないが、開発者の書いたコードを素直に受け入れるならば、 コードによって問題がないことを担保するためのテスト項目は変わる。 コーディングによってテスト項目は変わるか？質問に対していうと、 「コードレビューで問題が見つかったらコードを直すだけ。」というならば 直さないならばテスト項目は変わるってことでしょう？ テスト項目を変えないためにコーディングを直すっていうのは、 テスト項目が変わる原因の一つがコーディングであると言ってるのと 微妙にニュアンスは違うけど、結果として殆ど変わらないよ。 165 名前：デフォルトの名無しさん mailto:sage [2016/06/02(木) 00:53:04.14 ID:qX3K4vQy.net] >>160 > 仕様書から起こす入力に対する正しい出力をチェックするだけ それはなんのためにやっているの？ テストはバグを検出するためにやっていると思ったが、 コードに問題があると、バグを検出できないってことだよね？ 166 名前：デフォルトの名無しさん mailto:sage [2016/06/02(木) 00:53:06.73 ID:IPFd2Mdr.net] >>161 コーディングによってテスト項目は変わるか？云々は知らない。 お前が言ってることがおかしいってだけ。 テスターは要件の境界線をテストする。 コードが異常な境界線を基準としていたためにバグを見逃していたとしてもテスターの責任ではない。 どうしようもない。 167 名前：デフォルトの名無しさん mailto:sage [2016/06/02(木) 00:58:20.11 ID:55Jnw5v7.net] >>163 それも違う 境界なんてものは存在しない 本来は取り得る値すべてをチェックしなければならない でも客とテスターの間の取引で暗黙に間引いてるってだけの話 168 名前：デフォルトの名無しさん mailto:sage [2016/06/02(木) 00:59:05.09 ID:qX3K4vQy.net] >>163 だから責任問題の話なんかするつもり無いってばｗ どんなコードであっても、同じテストをすれば 同じ品質（バグがない）を担保できるような話をしてるから、 同じテストをしたとしても（そのテストに漏れがなかったとしても） コードにバグがないことを担保できないし、 コードの品質も同じにはならないよって話をしてるんだよ。 コードが悪ければ、品質を保つために必要なテスト項目は増えるし、 コードを直すことで、必要なテスト項目は減る。 （正確に言えば仕様書から起こした本来の最低限のテスト項目だけで済む） 169 名前：デフォルトの名無しさん mailto:sage [2016/06/02(木) 01:01:46.10 ID:IPFd2Mdr.net] >>165 責任だけの話じゃない。対応のしようがないって話。 要件上引数は正の数でなければならないとする。 ところがコードがアホで引数が100だとバグが発生するとする。 テストではそれが分からなかった。 どうすんの？って話。 170 名前：デフォルトの名無しさん mailto:sage [2016/06/02(木) 01:03:06.15 ID:55Jnw5v7.net] >>165 何度も言うけどソースコードからテスト項目は増えない ソースからテスト仕様書作ってる会社なんてないだろうよｗ 171 名前：デフォルトの名無しさん mailto:sage [2016/06/02(木) 01:07:07.95 ID:T7FoO03Y.net] だんだん ID:qX3K4vQy ID:IPFd2Mdr の主張がこんがらがってきた…… 172 名前：デフォルトの名無しさん mailto:sage [2016/06/02(木) 01:08:17.44 ID:qX3K4vQy.net] >>166 だからテストとは別にコードレビューをテスト前に行い、 悪いコードをあらかじめ直すしかないだろ？ 俺が品質ベースで考えてるから話がずれてるのか？ 俺はバグがないようにすることを目標として どんなテストが必要か？を考えてる。 だからバグを無くすためには、コードによって必要なテスト項目が変わってくる。 そしてコードを良くすることで、必要なテスト項目が減るという話をしてるんだよ。 仕様書からテストを起こすっていうのは、当然コードは見てないから 必要な（最低限の）テストは何か？だけを考えてる。 テストの効果（バグを見落とすかどうか）は考えておらず、 その効果はコードによってばらばらで、テストしてもバグを検出できるとは限らない。 この場合のテストの目的は何なんだろうかねｗ 173 名前：デフォルトの名無しさん mailto:sage [2016/06/02(木) 01:08:59.38 ID:IPFd2Mdr.net] >>169 うん。だからコードを直そうね。 テスト漏れじゃないね。 174 名前：デフォルトの名無しさん mailto:sage [2016/06/02(木) 01:12:05.80 ID:qX3K4vQy.net] >>167 > 何度も言うけどソースコードからテスト項目は増えない それはテストの効果（バグがないことの担保） を無視すればそうなるよね。 ソースコードからテスト項目は増えないが ソースコードが悪ければ、その増えないテスト項目では バグを見逃す可能性が高くなる。 テストの効果を低くしていいならば、 テスト項目は増やさなくていいよ。 そしてソースコードが汚いならばソースコードの方を直すんだろう？ なぜなら、ソースコードが汚ければテスト項目を 増やさなければならなくなるから（アレ？ｗ） 175 名前：デフォルトの名無しさん mailto:sage [2016/06/02(木) 01:12:26.96 ID:T7FoO03Y.net] 俺の理解 ID:qX3K4vQyの主張はコードからテストケース作る ID:IPFd2Mdrの主張は設計書からテストケース作る コードが設計書に書かれてることを満たしてるかどうかって コードから作ってたらわからないのでは……って疑問が…… なぜかコードだけ、設計書だけの0か100かに見えてしまってるので 勘違いしてたらごめん 176 名前：デフォルトの名無しさん mailto:sage [2016/06/02(木) 01:13:23.53 ID:qX3K4vQy.net] >>170 > うん。だからコードを直そうね。 > テスト漏れじゃないね。 コードを直さないとどうなる？ 同じ品質を保つにはテストを増やす必要があるよね？ えーと、それがコーディングによってテスト項目は 変わるってことだよねｗ コーディングによってテスト項目が増えるから コーディングを直すんだよね？ｗ 177 名前：デフォルトの名無しさん mailto:sage [2016/06/02(木) 01:14:50.74 ID:55Jnw5v7.net] >>169 どうにでも好きなように組んだらいいよ チェック項目は変わらない オブジェクト指向でも関数型でも これが設計の本質だ 単にソースコードに書く場所が違うだけ それがオブジェクト指向 こんなもんにマジになっちゃってどうするの? っていうIT業界の黒歴史 178 名前：デフォルトの名無しさん [2016/06/02(木) 01:16:20.73 ID:IPFd2Mdr.net] >>173 >>166 そりゃバグがあることが判明したらテストを追加すべきだろうね。 でも、そもそもテストが不足していたということじゃないね。 179 名前：デフォルトの名無しさん mailto:sage [2016/06/02(木) 01:18:59.63 ID:qX3K4vQy.net] >>172 俺の意見としては、テストとは別にコードレビューが必須であるということ。 仕様書からテストをおこすのは問題ないんだが、 そのテストで品質が保てるかどうかは コードで左右される。 コードが汚ければいくらまともなテスト行ったとしても それで品質を保つことは出来ない。 俺は品質を保つことを第一に考えてるので コードを直さずに品質を保つならばテスト項目� 180 名前：ｪ増えてしまうという話をしてる。 だからテスト項目を増やさずに品質を保つために、コードを直しましょうという話をしている。 で、最初の疑問「コーディングによってテスト項目は変わるか？」の 答えは、（品質を保つことを前提にすると）コーディングによってテスト項目は変わる。 悪いコードだと（品質を保つために）テスト項目が増えてしまう。だからコーディングを直しましょう。 [] [ここ壊れてます] 181 名前：デフォルトの名無しさん [2016/06/02(木) 01:21:24.41 ID:IPFd2Mdr.net] >>176 コードレビューで仕様の境界とは違うところで問題が見つかったらコードを直すだけ。 そんなのテスト作成とは関係ない。 182 名前：デフォルトの名無しさん mailto:sage [2016/06/02(木) 01:23:15.23 ID:qX3K4vQy.net] >>175 > そりゃバグがあることが判明したらテストを追加すべきだろうね。 リリースした後で、バグが有りました。すいません。ですむ会社なら それでもいいけどさぁｗ 「ちゃんとテストしたの？」の答えに テストは不足していません！ちゃんとテストしました！ ちゃんとテストしたのに、コードが悪かったんです！ ですむなら、それでもいいけどさぁｗ 理想の世界であれば、テストが不足してないのは事実だろうが、 そのテストで十分であるためには、コードが綺麗でなければならず、 コードが汚ければ、多くのテストが必要になるから コードレビューをして綺麗なコードにしましょうや。 それができて初めて、テストする意味が生まれる。 183 名前：デフォルトの名無しさん mailto:sage [2016/06/02(木) 01:24:18.99 ID:qX3K4vQy.net] >>177 > コードレビューで仕様の境界とは違うところで問題が見つかったらコードを直すだけ。 だから何度もそう言ってるだろうが。 人の話聞けよｗ 184 名前：デフォルトの名無しさん [2016/06/02(木) 01:24:53.24 ID:IPFd2Mdr.net] >>178 だからさ、要件の境界とは違うところでコードがアホ過ぎるせいでバグがあったとして見つける手段は？ 見つける手段がないのに直そうと言っても意味ない。 185 名前：デフォルトの名無しさん [2016/06/02(木) 01:25:55.40 ID:IPFd2Mdr.net] >>179 ？？ だったらいちいち反論すんなよ。 186 名前：デフォルトの名無しさん mailto:sage [2016/06/02(木) 01:26:39.31 ID:qX3K4vQy.net] 俺がはテストが足りないって言ってるんじゃないんだぜ？ 品質を保つことを前提にするならば、 コードが汚ければ、品質を保つために必要なテストが増えてしまうから、 まずコードレビューしてコードを綺麗にしましょうって話。 コードが綺麗な状態であって初めて、仕様書から起こしたテストで十分だと言える。 187 名前：デフォルトの名無しさん mailto:sage [2016/06/02(木) 01:29:14.56 ID:qX3K4vQy.net] >>181 > だったらいちいち反論すんなよ。 お前が反論してるんだろｗ っていうかお前のは反論じゃない。 俺が言っていることと違うことをぶつけているだけ。 俺が言ってるのは、コードが汚いならば（品質を保つために） 必要なテストは増えるって話。 コードが汚くても、テストは増やさないで品質が保てるような 話をしているから、その発想は抜けがあるよってこと。 188 名前：デフォルトの名無しさん mailto:sage [2016/06/02(木) 01:29:26.96 ID:soSMk704.net] そんなときこそユニットテスト コード改変の前後でエンバグしたかどうかがすぐわかります なおユニットテストそのものの品質を保つかが課題 189 名前：デフォルトの名無しさん mailto:sage [2016/06/02(木) 01:30:23.03 ID:T7FoO03Y.net] >>176 了解 回答ありがとう 190 名前：デフォルトの名無しさん mailto:sage [2016/06/02(木) 01:30:30.71 ID:qX3K4vQy.net] >>180 > 見つける手段は？ それもテスト前にコードレビューするって何度も言ったはずだが？ 汚いコードは直さないと、テストした所で効果は低い 191 名前：デフォルトの名無しさん [2016/06/02(木) 01:31:11.16 ID:IPFd2Mdr.net] >>183 本来的にはテストは要件にしたがって動作することを確認するためのもの。 コードがきれいか汚いかとか関係ない。 192 名前：デフォルトの名無しさん [2016/06/02(木) 01:32:06.67 ID:IPFd2Mdr.net] >>186 コードレビューで見つかったなら直せ。以上。 テストとの直接の関係はない。 193 名前：デフォルトの名無しさん mailto:sage [2016/06/02(木) 01:33:09.51 ID:qX3K4vQy.net] >>187 > 本来的にはテストは要件にしたがって動作することを確認するためのもの。 その確認の手間がコードによって変わってしまうんだよ。 すでにコードで例示したけど？ 194 名前：デフォルトの名無しさん [2016/06/02(木) 01:33:30.12 ID:dD1ozz1q.net] Haskellならテスト要らないですよ？ コンパイルできた時点でバグが無いことが保証されるから。 195 名前：デフォルトの名無しさん [2016/06/02(木) 01:34:23.43 ID:IPFd2Mdr.net] >>189 コードがアホなだけ。テストではどうしようもない。 と結論が出てる。 196 名前：デフォルトの名無しさん mailto:sage [2016/06/02(木) 01:34:39.66 ID:55Jnw5v7.net] >>189 だから変わらないって 本来は取りうる値の範囲をすべてチェックするんだから 197 名前：デフォルトの名無しさん mailto:sage [2016/06/02(木) 01:34:52.13 ID:qX3K4vQy.net] >>188 「直接の関係はない」ってことは やっぱり間接的に関係があるって認めるんだｗ そりゃコードによって品質を保つための テストは変わりますからねｗ バグが有るかどうか知ったこっちゃない。 俺はテストをちゃんとやった。 テストしたのに漏れたのはコードが悪いんだ！ ですむなら良い世界だねｗ 198 名前：デフォルトの名無しさん mailto:sage [2016/06/02(木) 01:35:31.60 ID:55Jnw5v7.net] 勝手に間引いてるのはテスターの責任 199 名前：デフォルトの名無しさん [2016/06/02(木) 01:36:12.80 ID:IPFd2Mdr.net] >>193 コードレビューで問題が見つかったらテストケースを追加してもいいよねってだけ。 200 名前：デフォルトの名無しさん [2016/06/02(木) 01:36:59.90 ID:dD1ozz1q.net] これからは関数型ですよ。 Haskell以外淘汰されます。 201 名前：デフォルトの名無しさん [2016/06/02(木) 01:37:36.91 ID:IPFd2Mdr.net] >>196 Haskellとか既に淘汰されてるんだが。 202 名前：デフォルトの名無しさん mailto:sage [2016/06/02(木) 01:38:47.83 ID:qX3K4vQy.net] >>192 > 本来は取りうる値の範囲をすべてチェックするんだから うん、ネタなのは分かってるよ（笑） 分かってて聞くけど、ある数値を二乗する関数があったとして Rubyで取りうる値の範囲はどうなるかい？ なんでRubyと言ったかというと、RubyではIntの範囲を超えると 自動的にBignumに拡張されるからとても大きな整数を扱えるんだぜ！ 203 名前：デフォルトの名無しさん mailto:sage [2016/06/02(木) 01:39:44.45 ID:qX3K4vQy.net] >>195 > コードレビューで問題が見つかったらテストケースを追加してもいいよねってだけ。 誰がやんの？ テスターのお仕事？ 204 名前：デフォルトの名無しさん [2016/06/02(木) 01:40:36.22 ID:IPFd2Mdr.net] >>199 コードレビューって自分で言ったんだから知ってるだろ。 分かってることをいちいち聞くな。 205 名前：デフォルトの名無しさん [2016/06/02(木) 01:40:47.43 ID:dD1ozz1q.net] Haskell使えばテスト必要ないですよ？ 206 名前：デフォルトの名無しさん mailto:sage [2016/06/02(木) 01:42:30.76 ID:55Jnw5v7.net] スレの本題にくっつけると コードの記述方法でチェック項目は変わらない つまりオブジェクト指向でも関数型でも品質は上がらない 言い換えればコードの記述方法で品質は上がらない 品質を上げるにはしっかり仕様書を書いて しっかり書いた仕様書からテスト仕様書を起こすこと ソースの記述方法は品質を決定する計算式に入ってません（笑） おｋ? 207 名前：デフォルトの名無しさん mailto:sage [2016/06/02(木) 01:43:13.49 ID:qX3K4vQy.net] >>200 せやね。 コードが悪ければコードレビューで テスト項目が追加される。 コードが悪ければ、テスト項目が追加される。 おや？ コーディングによってテスト項目が変わるって話に戻ったか。 208 名前：デフォルトの名無しさん [2016/06/02(木) 01:44:21.91 ID:IPFd2Mdr.net] >>203 「追加してもいい」 この意味が分からんの？ 日本語からやり直せ。 209 名前：デフォルトの名無しさん mailto:sage [2016/06/02(木) 01:46:16.79 ID:55Jnw5v7.net] 今回もオブジェクト指向が幻想技術ということが決定したな 210 名前：デフォルトの名無しさん [2016/06/02(木) 01:46:33.24 ID:IPFd2Mdr.net] >>205 基地外 211 名前：デフォルトの名無しさん mailto:sage [2016/06/02(木) 01:47:36.18 ID:3RkkmY6H.net] さて、スレが流れた所で話を戻すかｗ >>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つになるわけだが、ここまでの話で明らかなように 「コーディングの仕方でテスト項目は変わる」というか「悪いコードだとバグがないことを担保するためのテスト項目は増える」 212 名前：デフォルトの名無しさん mailto:sage [2016/06/02(木) 01:49:05.94 ID:3RkkmY6H.net] 何だ俺、最初から一貫して同じこと言ってるやんｗ 213 名前：デフォルトの名無しさん mailto:sage [2016/06/02(木) 01:50:22.82 ID:55Jnw5v7.net] >>207 だからvalの取りうる範囲チェックするだろ 中間値だけとか間引くのはテスターが勝手にやってるだけの話 チェック項目は変わらない 214 名前：デフォルトの名無しさん mailto:sage [2016/06/02(木) 01:51:43.92 ID:3RkkmY6H.net] >>209 だから、そのvalの取りうる値ってなんだよ？ｗ >>198の質問にも答えてないぞお前ｗ 215 名前：デフォルトの名無しさん mailto:sage [2016/06/02(木) 01:53:10.76 ID:ehI/NdEG.net] >>176 完全に横だが、、、 そちらの意見自体に文句はない。つまり、コード品質最優先で同意だ。 付け加えるとしたら、>>143の例ならカバレッジで確認できる。 つまりC1(方言かもしれんが各分岐）まで含めれば例示されたバグは落とせる。 あと、仕様から起こしたテストを一通りやらないと「実装忘れ」を検出できない。 例えば、関数電卓を作ったとして、色々ある関数の一つを実装し忘れたとか。 実装漏れをテストではなくコードレビューで落とすことは出来るが、これはポリシーの問題となる。 仕様から起こしたテストで品質が上がるかというと、多分無理だ。これは競合を落とせない。 各競合を全部コードレビュー時にテストに追加するという手もあるが、これは追加漏れが発生する。 だから品質を上げるためには結局ランダムテストしかないと俺は思っている。 216 名前：デフォルトの名無しさん mailto:sage [2016/06/02(木) 01:55:40.16 ID:55Jnw5v7.net] >>210 仕様書に書いてあるだろ? ないの? そしたら不具合ですらないんじゃない? 217 名前：デフォルトの名無しさん [2016/06/02(木) 02:01:57.34 ID:IPFd2Mdr.net] >>211 カバーできてないことが判明 コードを直す テストを追加するかは任意 218 名前：デフォルトの名無しさん [2016/06/02(木) 02:03:26.51 ID:IPFd2Mdr.net] >>211 ランダムテストって謎。 ランダムテストでアホなコードが漏れたらって話だろ。 なんでランダムテストさえすればアホなコードがすべて網羅できるって前提なんだよ？ 219 名前：デフォルトの名無しさん mailto:sage [2016/06/02(木) 02:25:10.08 ID:ehI/NdEG.net] >>213-214 いや、複数箇所に冗長に記述があった時、それらが整合しているかだろ？ 見た瞬間分かればいいけど、クラスをまたいでいたりすると単純には削除できないケースもある。 この場合はカバレッジ100%なら整合している可能性が高い事は言える。 （ただし二重に冗長な場合は無理だが） ランダムテストは動作の確認とカバレッジを稼ぐため。つまりバグの検出。 ランダムテスト自体では「品質の高い＝美しいコード」は得られない。 ただ、コードの品質って大前提として「バグがないこと」だろ？(コードが美しいことではなくて) これについてはランダムテストが一番だと思っている。 すまんがもう寝る。 220 名前：デフォルトの名無しさん [2016/06/02(木) 03:00:45.20 ID:dD1ozz1q.net] あ、逃げた。 221 名前：デフォルトの名無しさん mailto:sage [2016/06/02(木) 04:13:03.69 ID:soSMk704.net] マジレスするとECPで大抵のテスト分けは解決できる あとは重箱の隅をつつく価値があるかどうか 222 名前：デフォルトの名無しさん [2016/06/02(木) 04:24:49.52 ID:dD1ozz1q.net] マジレスするとHaskell使えばテストは必要ない。 テストでバグを発見できるというのは甘え。 223 名前：デフォルトの名無しさん mailto:sage [2016/06/02(木) 06:09:23.71 ID:a5hqyyy7.net] そう Haskellを使っていれば交通事故を起こさない自動車だって作れた なお完成は２４世紀ごろを予定しております 224 名前：デフォルトの名無しさん mailto:sage [2016/06/02(木) 06:54:53.87 ID:ehI/NdEG.net] すまぬ。「ランダムテスト」は方言で、標準語ではどうやら「自動テスト」と呼ばれるようだ。 (モデルを作成し、ランダムな入力を食わせて出力をチェックする） 混乱させてすまん。 225 名前：デフォルトの名無しさん mailto:sage [2016/06/02(木) 08:36:32.58 ID:jj0I32l4.net] >>207 ＞たとえば数値が偶数か奇数かを文字列で返す関数があったとしよう。 ＞これのチェック項目はfoo(0)とfoo(1)の2つで十分だろう。 充分じゃない、テスト仕様書がそうなってたらテスト仕様書書いた奴氏ねって言っていい、コードがどうなっているかはこの時点では関係ない 226 名前：デフォルトの名無しさん mailto:sage [2016/06/02(木) 09:21:14.08 ID:qVro3+K+.net] >>218 あんたHaskell信者に見せかけたアンチだろｗ HaskellにはHaskellの良さがあるけど、俺は結局C++に戻ってきた。 最近はCまで戻ろうかと検討してる。 もしくはLispを試してみようかなと。 227 名前：デフォルトの名無しさん mailto:sage [2016/06/02(木) 09:59:19.16 ID:9Sgsnltg.net] 設計=仕様書から書けるテストはブラックボックステストで、 コードから書けるテストはホワイトボックステスト。 ブラックボックステストで全ての取りうる値を入力するなんて非現実的だから、境界条件を考慮してテストセットを作る。 ホワイトボックステストはどれだけ網羅するかにもよるけど、条件分岐があったらその全てを通るテストセットを作る。 テストで得られる保証の度合いで言うならホワイトボックス>ブラックボックスなのは確かだけど、 中身まで見れる状態になっていないとホワイトボックステストは書けない。 開発プロセスがトップダウン方式だったりテスト駆動開発だと、書けるテストはブラックボックステストにならざるを得ない、という現実的な話。 そこで満足するか、更なる品質保証のためのホワイトボックステストを書くかはコストと相談しましょう。 Haskellでも同じ。テストを書く必要が無いのは依存型やRefinment typesを使える言語だけ。 228 名前：デフォルトの名無しさん mailto:sage [2016/06/02(木) 10:42:12.02 ID:x8NBN55x.net] >>182 > コードが綺麗な状態であって初めて、仕様書から起こしたテストで十分だと言える。 その仕様書とやらが、コードをC0カバレッジできるレベルで書かれてるならそうだろうな。 229 名前：デフォルトの名無しさん mailto:sage [2016/06/02(木) 10:43:30.50 ID:x8NBN55x.net] >>220 > すまぬ。「ランダムテスト」は方言で、標準語ではどうやら「自動テスト」と呼ばれるようだ。 いや、呼ばれない。自動テストとはマニュアルテストの反語。 230 名前：デフォルトの名無しさん mailto:sage [2016/06/02(木) 10:58:37.56 ID:HMnON+Ay.net] >>220 QuickCheckって呼んでるわ 231 名前：デフォルトの名無しさん mailto:sage [2016/06/02(木) 10:59:58.45 ID:qVro3+K+.net] 俺もそれのことかなと思った。 data-driven testing toolと呼ぶらしい。 232 名前：デフォルトの名無しさん mailto:sage [2016/06/02(木) 11:24:00.72 ID:tJT0ttjQ.net] >>223 ある条件判定がfalseになったんだけど それが正しいか間違ってるかってどうやって判定すんの? ソースコードだけにその答えがあるの? 233 名前：デフォルトの名無しさん mailto:sage [2016/06/02(木) 11:30:53.69 ID:x8NBN55x.net] >>228 > ある条件判定がfalseになったんだけど > それが正しいか間違ってるかってどうやって判定すんの? もっと具体的に。 234 名前：デフォルトの名無しさん mailto:sage [2016/06/02(木) 12:11:08.77 ID:tJT0ttjQ.net] >>229 if（val==false） 235 名前：デフォルトの名無しさん mailto:sage [2016/06/02(木) 12:34:31.31 ID:j1kGed0y.net] 朝。 さんさんと照り付ける太陽がS2715Hに映り込む。 純度100%のグレアモニター、S2715Hに自分の影がシャープに映り込むと、一日が始まる。 見ているものが正確で、映っているものは色が正確で、光量も正確。 よい生活はよい製品から得られる。 236 名前：デフォルトの名無しさん mailto:sage [2016/06/02(木) 12:46:55.06 ID:x8NBN55x.net] >>230 それは一体どこの話なんだ？ そもそも、（単体/unit）テストが何なのか理解してるか？ 237 名前：デフォルトの名無しさん mailto:sage [2016/06/02(木) 12:48:55.39 ID:tJT0ttjQ.net] >>232 unkoクラスのgetPPメソッド 238 名前：デフォルトの名無しさん mailto:sage [2016/06/02(木) 12:50:25.29 ID:soSMk704.net] ifの中で真偽値と比較するコードなんて捨ててしまえ 239 名前：デフォルトの名無しさん mailto:sage [2016/06/02(木) 12:54:33.11 ID:x8NBN55x.net] >>233 ということであれば、単体/unitテストでは、正しいも間違っているも判定しない。 240 名前：デフォルトの名無しさん mailto:sage [2016/06/02(木) 14:26:28.50 ID:fuTkOmr9.net] このように意味のないことを堂々巡りに考えるのがOOP脳患者 無駄なことに時間を費やしたくない人は OOPが得意な部分だけを上手に利用することだけを考えておけばよい ほとんどの実用的な言語がマルチパラダイムを選択していることからもわかる通り 当たり前に得手不得手があるし 一つの考え方だけでうまくいくほど世の中単純ではないことは子供以外は誰でも知っている 241 名前：デフォルトの名無しさん mailto:sage [2016/06/02(木) 16:51:41.22 ID:9Sgsnltg.net] >>228 コードだけ見て判断できるものもあるし、仕様書読まないと判断できないものもあるとしか言えない。 どっちを参照しても分からないなら作った人に聞くべきだけど、それはテストじゃなくてレビューになる。 それとも仕様書無しでソースあり、さあテストを書けって場合を考えている？ そんな苦役を振られたら、仕様書を作って欲しいのか確実に動かないバグを潰して欲しいのか確認するところから始めましょう。 242 名前：デフォルトの名無しさん mailto:sage [2016/06/02(木) 18:22:00.20 ID:55Jnw5v7.net] >>237 いや、オブジェクト指向だとテストが減るとか言ってるアホがいたから 243 名前：デフォルトの名無しさん mailto:sage [2016/06/02(木) 19:13:46.82 ID:IPFd2Mdr.net] >>238 オブジェクト指向の目的聞かれて回答しないままトンずらした奴だろ。 244 名前：デフォルトの名無しさん mailto:sage [2016/06/02(木) 22:51:27.39 ID:3RkkmY6H.net] >>212 > 仕様書に書いてあるだろ? 仕様書には「整数」って書いてあるけど、 そしたら、無限にある整数を全部テストしろって話でしょう？ｗ 245 名前：デフォルトの名無しさん mailto:sage [2016/06/02(木) 23:08:39.30 ID:soSMk704.net] そんなときこそFormal methods 複雑になるとUndecidableなのが玉に瑕 246 名前：デフォルトの名無しさん mailto:sage [2016/06/02(木) 23:26:10.98 ID:55Jnw5v7.net] >>240 駄目な仕様書だな 上限も下限も定義されてないでモノなんて作れっかよ 全く仕事やってない証拠 オブジェクト指向なんかどうでもいいから 設計書きっちり書けよって話 247 名前：デフォルトの名無しさん mailto:sage [2016/06/02(木) 23:37:42.96 ID:3RkkmY6H.net] >>242 > 駄目な仕様書だな > 上限も下限も定義されてないでモノなんて作れっかよ 作れるだろ？Pythonは無限リストを作れるのが特徴だ。 無限リストには上限も下限もない。 248 名前：デフォルトの名無しさん mailto:sage [2016/06/02(木) 23:40:01.75 ID:3RkkmY6H.net] RubyのBigNumも上限も下限もないな。 docs.ruby-lang.org/ja/2.2.0/class/Bignum.html あえて言えばメモリサイズによる制限は受けるが、 じゃあメモリサイズいっぱいの桁数の数値（何桁だと思う？ｗ）を 全部テストするのかとｗ 249 名前：デフォルトの名無しさん mailto:sage [2016/06/02(木) 23:58:48.20 ID:fuTkOmr9.net] ほら頭悪いでしょ 250 名前：デフォルトの名無しさん mailto:sage [2016/06/03(金) 00:01:57.95 ID:57ESL53T.net] >>245 仕方ないんじゃないかな？ 馬鹿なんだからそういういちゃもんを付けるしかないんだと思うよ。 251 名前：デフォルトの名無しさん mailto:sage [2016/06/03(金) 00:04:49.79 ID:fpUAqgyP.net] そもそもテストを行う実時間の問題だから 組合せ爆発でも起こしたら、本当に何万年とか かかってしまうのがテストなんだよね。 仕様書に上限や下限をつけた所でなんの対策にもなっていない。 252 名前：デフォルトの名無しさん mailto:sage [2016/06/03(金) 00:08:30.87 ID:LbxBbQld.net] 下限や上限が決まっていたら、閾値界隈のテストできるでしょ 下限も上限も決まってなかったら本当にテストできない 下限も上限も決めないのは馬鹿

---

---

[ 続きを読む ] / [ 携帯版 ]

read.cgi ver5.27 [feat.BBS2 +1.6] / e.0.2 (02/09/03) / eucaly.net products.
担当:undef