トップページ⇒tech
1002コメント412KB

テストしにくいコードをテストする方法教えて下さい

レス数が1000を超えています。これ以上書き込みはできません。
0001デフォルトの名無しさん2012/04/14(土) 21:59:51.59
ここで言うテストっていうのは
ユニットテストみたいなものね。

人間がぽちぽち操作してやるテストじゃありません。
0002デフォルトの名無しさん2012/04/14(土) 22:00:08.74
テストしにくいコードって何？
0003デフォルトの名無しさん2012/04/14(土) 22:35:11.00
このスレッドは天才チンパンジー「アイちゃん」が
言語訓練のために立てたものです。

アイと研究員とのやり取りに利用するスレッドなので、
関係者以外は書きこまないで下さい。

　　　　　　　　　　　　　　　　　　京都大学霊長類研究所
0004デフォルトの名無しさん2012/04/14(土) 22:35:14.93
テストしやすいコードを書き換える
0005デフォルトの名無しさん2012/04/14(土) 22:43:22.87
>>4
どのように書き換えるのですか？
0006デフォルトの名無しさん2012/04/14(土) 23:03:57.47
俺がテストコードを書けないコードはない・・・

っていう厨2病のテストエンジニアが主人公の漫画でも小説でもいいから書いてくれ
0007デフォルトの名無しさん2012/04/14(土) 23:26:23.85
>>5
コードが単体テストし難くなっている原因による

その単体テストがし難くいコードが具体的に示されるまでは、
テストし難い部分を切り分けるという極一般的で大雑把なアドバイスしかできない
0008デフォルトの名無しさん2012/04/14(土) 23:52:46.58
よくわかんないけど>>1は首だ
0009デフォルトの名無しさん2012/04/14(土) 23:55:16.72
UIは面倒くさい。毎回「どうやってテストするの？」って思う。
0010デフォルトの名無しさん2012/04/14(土) 23:58:20.61
画像と比較すればいいのではないか？
0011デフォルトの名無しさん2012/04/15(日) 00:17:34.86
>>9
マウス操作やキーボード操作、メッセージを発行を
スクリプトで自動制御するアプリを DL してくるか自作して、
それで GUI 部分をテストする

もちろんその前に、ビジネスロジックなどGUI以外の部分のテストは済ませておく
（当然、ちゃんと切り分けられていることが前提だが）

ついでにネットワーク処理のテストは、
たしか任意の負荷をかけられるテスティングツールがあったはず
0012デフォルトの名無しさん2012/04/15(日) 00:20:33.13
>>11
もう少し具体的に言うと、
アプリ側にGUI操作する度にログを吐き出す仕組みを作っておき、
自動操作スクリプトで操作させた結果のログと期待するログとを比較する
0013デフォルトの名無しさん2012/04/15(日) 07:57:08.82
ネットワーク越しにあるGUIで操作するものとか
自動でやるの厳しいよね
0014デフォルトの名無しさん2012/04/15(日) 11:44:31.38
>>13
どうして？
0015デフォルトの名無しさん2012/04/15(日) 18:17:12.63
>>1
レガシーコード改善ガイド
0016デフォルトの名無しさん2012/04/15(日) 18:43:15.70
>>11 せれにうむとか
0017デフォルトの名無しさん2012/04/15(日) 20:38:07.15
>>13
逆にネットワークから流れてくる同じデータ流せばいいから簡単そう
0018デフォルトの名無しさん2012/04/15(日) 21:49:54.92
>>16
Web系ならそうっすね
0019デフォルトの名無しさん2012/04/15(日) 22:05:01.56
人に頼む
0020デフォルトの名無しさん2012/04/15(日) 22:50:14.56
>>19
高すぎる
0021デフォルトの名無しさん2012/04/16(月) 16:05:28.75
テストしにくいコードって
・居眠りしてる間に小人さんが書いてくれた
・設計のバグ
・コーダーのバグ
とかのこと？
0022デフォルトの名無しさん2012/04/16(月) 16:16:40.58
いまだにコーダーとか言ってる人は、Webデザイナーの人？
0023デフォルトの名無しさん2012/04/16(月) 16:36:18.01
>>22
いや、写経するだけの人っているじゃん？
0024デフォルトの名無しさん2012/04/16(月) 17:13:20.93
>>23
「写経」というのが、詳細な設計情報をただ単にコードに落とすというのを指してるとすると、
そんな詳細な設計書を書く所がいまだに存在するのかという疑問になる。
0025デフォルトの名無しさん2012/04/16(月) 17:36:52.84
>>23
写経がなんだかわかりませんが。
とにかく、特殊な分野の人なんですね。
0026デフォルトの名無しさん2012/04/16(月) 17:45:34.37
>>25
いや、そうでもないよ。
おそらく君が日常的に接しているソフトの大半はその写経で作られてる。
0027デフォルトの名無しさん2012/04/16(月) 17:51:32.35
>>26
その写経とやらが具体的にどういう行為なのかわからんのだが、
詳しく説明してみてくれんかな
0028デフォルトの名無しさん2012/04/16(月) 17:53:15.16
詳細な設計情報をただ単にコードに落とすというのを指してるとすると、
0029デフォルトの名無しさん2012/04/16(月) 18:04:56.30
とすると？
0030デフォルトの名無しさん2012/04/16(月) 18:15:42.28
「写経」というのが、詳細な設計情報をただ単にコードに落とすというのを指してるとすると、
コーダーとやらはその設計情報通りに単にコードに落としてるだけなので、
テストし辛いとしたらコーダーのせいではなく、設計者のせいだね。
0031デフォルトの名無しさん2012/04/16(月) 18:16:31.96
>>26
君時代に取り残されてるよ
コーダってもうWeb業界でしか使わないよ
0032デフォルトの名無しさん2012/04/16(月) 19:22:05.53
>>31
うん、そういう人たちはPGって呼ばれてるね。
0033デフォルトの名無しさん2012/04/16(月) 19:22:29.27
Web業界のことは知らないけど。
0034デフォルトの名無しさん2012/04/16(月) 19:58:34.18
>>24
詳細設計書と呼ばれる自然言語で書かれたゴミしか
生産できないバカの雇用を守るために存在するよ
0035デフォルトの名無しさん2012/04/16(月) 20:45:53.15
オールグリーンだのコードカバレッジがどうのだの言っても
本質的にテストでは欠陥が存在しないことが証明できない
つまりこれからは形式的手法の時代だ

勿論そんな時代は来ないがな！
0036デフォルトの名無しさん2012/04/16(月) 22:21:31.08
>>26
たとえば、写経してできたコードが
クイックソートのコードだとして、

そのクイックソートの詳細な設計書ってのは
どんなのだい？
0037デフォルトの名無しさん2012/04/16(月) 22:24:53.58
今時クィックソートなんてコーディングしないよ。
0038デフォルトの名無しさん2012/04/16(月) 22:56:27.58
多角形の細分化(一つの三角形を4つに分け、分けた
三角形を更に4つに分けるを繰り返す)で、4個の三角形の辺を
正しい方向で巡らないと穴が開いたりすんだよね。
こんなのどうやってテストすんだろ。

static bool Subdivision( RasterLogic &target, size_t deeps, const Util::ConstArray<inner_color_type&,3> &tri_colors, const Util::ConstArray<inner_vector_type&,3> &vertices )
{
　if( !deeps ) return /* 省略 */;
　const Util::ConstArray<inner_vector_type&,3>
　　&half_vertices = Values
　　(
　　　vertices[0] + ( vertices[1] - vertices[0] ) / 2,
　　　vertices[1] + ( vertices[2] - vertices[1] ) / 2,
　　　vertices[0] + ( vertices[2] - vertices[0] ) / 2
　　);
　const Util::ConstArray<inner_color_type&,3>
　　&half_colors = Values
　　(
　　　Color( Values( tri_colors[0], tri_colors[1] ) ),
　　　Color( Values( tri_colors[1], tri_colors[2] ) ),
　　　Color( Values( tri_colors[2], tri_colors[0] ) )
　　);
　bool internal = true;
　--deeps;
　// 隣接する三角の辺の向きを揃えないと小さい穴が開く
　internal &= Subdivision( target, deeps, Values( tri_colors[0], half_colors[0], half_colors[2] ), Values( vertices[0], half_vertices[0], half_vertices[2] ) );
　internal &= Subdivision( target, deeps, Values( half_colors[0], tri_colors[1], half_colors[1] ), Values( half_vertices[0], vertices[1], half_vertices[1] ) );
　internal &= Subdivision( target, deeps, Values( half_colors[2], half_colors[1], tri_colors[2] ), Values( half_vertices[2], half_vertices[1], vertices[2] ) );
　internal &= Subdivision( target, deeps, Values( half_colors[0], half_colors[2], half_colors[1] ), Values( half_vertices[0], half_vertices[2], half_vertices[1] ) );
　return internal;
}
0039デフォルトの名無しさん2012/04/16(月) 23:01:55.02
法線が揃ってるかどうかをチェックすればいいんじゃないの？
0040デフォルトの名無しさん2012/04/16(月) 23:22:52.56
法線ってどういう事？
全部同じ方向に回ってたんじゃ穴が開くんだけど。
あと、関数のテストだからテストコードの作り方で教えてもらえるとありがたいな。
0041デフォルトの名無しさん2012/04/16(月) 23:29:56.85
>>38
「穴が開いたりすんだよね」 と言うが、
穴が開いたかどうかを君はどうやって認識してるんだ？

同義だが、正しい方向かどうかを「君は」何を以て判断してるんだ？
0042デフォルトの名無しさん2012/04/16(月) 23:34:42.55
>>41
前者は出力した画像
後者は理屈(理論上の正しい計算式)

画像での確認だけど、ある頂点の組み合わせを指定して
三角形に穴が開くことは解っても、どんな頂点の組み合わせでも
穴が開かない事を確認するのは難しいんだよね。
結局後者の理屈だのみ。
0043デフォルトの名無しさん2012/04/17(火) 00:00:29.23
>>42
> どんな頂点の組み合わせでも
> 穴が開かない事を確認するのは難しいんだよね。

本当に難しいのか？

細分化する前の多角形を塗りつぶした画像と、
細分化した後の全ての三角形を塗りつぶした画像は、
（細分化が正しく処理されれば）ぴったりと一致するのでないのか？
0044432012/04/17(火) 00:02:56.40
まぁ、効率を求めると、画像よりもハーフエッジの考え方を用いた方が良いんだけど、
思考の出発点としては画像を用いてもそれほど難しくない思うぞ
0045デフォルトの名無しさん2012/04/17(火) 00:16:11.26
>>43
頂点座標の選び方次第で、辺のめぐり順が間違ってても、
一致することもあるんだよね

このケースではハーフエッジをどう使うの？
0046デフォルトの名無しさん2012/04/17(火) 00:19:27.17
もしかしたら、誤解があるかも知れないから補足。
穴が開くってのは、陰面消去てきな話じゃなくて、
座標の誤差で三角同士の間に1～2pixelぐらいの穴が
開くってことね。
0047デフォルトの名無しさん2012/04/17(火) 00:31:37.80
>>46
それはそもそもアルゴリズムが間違ってるんじゃね？
表示部分で浮動小数の座標を受け付けないようになってるとか。
0048デフォルトの名無しさん2012/04/17(火) 00:39:18.31
高速化と精度のため整数でやってるけど、理屈通り正しくやれば誤差は発生しないよ。
あと、ここで聞いてるのは、バグの潰し方じゃなくてテストの仕方ね。
>>38は正しく動くけど、式が正しいか検証するためのテストはどうしたらいいってのが本題です。
0049デフォルトの名無しさん2012/04/17(火) 00:52:11.81
> 式が正しいか検証するためのテストはどうしたらいいっての
そんなもん、テストで検証することじゃなくてコードレビューでもして
チェックすることだとおもうが。
(テストで確認するとすれば、境界値の確認とかだろう)

テストってのは「これだけの動作確認をしたところ、問題ありませんでした」ってのを
示すためのものであって、それ以上のものではない。
0050デフォルトの名無しさん2012/04/17(火) 00:58:18.37
じゃある範囲の座標で正しく動く事を保証するテストなら
1000x1000は保証するとして、1000x1000の座標全ての組み合わせを
試せばいいんでしょ。問題は、その結果確認を如何に自動化するかだけど
0051432012/04/17(火) 00:59:14.42
>>45
確認なんだが、細分化してできた全ての三角形について、
それをレンダリングするとき、頂点をたどる方向は同じ順だよな
たとえば全て反時計回りに頂点をたどるとか
（たとえば OpenGL を使って三角形をレンダリングするならそうなる）

それを前提で話すんだが、細分化してできた隣同士の三角形について、
それらが共有する辺のハーフエッジは互いに逆方向を向いている
もし同じ方向を向いていたら、どちらかの三角形が裏を向いていることになる
（どちらの三角形かは時計回り、反時計回り、どちらを正方向とするかによる）

これを使って結果の正しさをテストできるはずだ

テストではなく正しさを「証明」したいのなら構造的帰納法を使う

もし、最初に確認した私の認識が違っているのなら、
私の考えを改めないといけないから、>>40 の意味を詳しく教えてほしい
0052デフォルトの名無しさん2012/04/17(火) 01:08:40.20
>>51
回転方向は一定じゃないよ。三角で表現すると難しいから四角で表すけどこんな感じ。
　←　→　←
↓　↑　↓　↑
　→　←　→
３個の四角のそれぞれ隣接する辺が逆向きにならないようにしないといけない。
逆向きにすると四角同士が共有する頂点に誤差が発生し、頂点が隣接する部分に穴が開くんだ。
だから、全ての辺のめぐりを同じ方向にすることはできないよ。
これが三角形でも発生するわけ。
0053デフォルトの名無しさん2012/04/17(火) 02:44:49.47
頑張って色々テストしてくれるAIつくればいいじゃんwwwwwwwwww
0054432012/04/17(火) 07:39:01.85
>>52
共有する辺のハーフエッジを互いに逆向きにしようと、同じ向きにしようと、
そんな事で隣り合う三角形の間に１ピクセルでも隙間が出ることはない
今時の普通のレンダリングエンジンを用いている限りあり得ない
（OpenGL だろうが、GDI だろうが、Cairo だろうが）

２つの三角形ＡとＢがあるとする
三角形Ａを構成する３つの頂点の座標をそれぞれ a1、a2、a3 とし、
三角形Ｂを構成する３つの頂点の座標をそれぞれ b1、b2、b3 とする
モデル空間の座標でも、ラスター空間の座標でもなんでもいいし、
座標値は浮動小数点でも整数でも有理数でもなんでもいい

このとき、a1 と b1 が同値でかつ a2 と b2 が同値なら、
線分 [a1, a2] と 線分 [b1, b2] は同一ピクセルがレンダリングされる
レンダリングエンジンは普通そのようにレンダリングするように作られている
たとえ１ピクセルでもずれることはない（ずれるなら欠陥品）

もし君がやったら穴が開いたというのなら、
a1 と b1 が同値でない、または a2 と b2 が同値でないのだろう
頂点および辺を「共有」するのに同値でない値を生成する君のアルゴリズムに問題がある
共有する辺の２つのハーフエッジの向きには関係ない

Catmull–Clark など、普通のサブディビジョンのアルゴリズムなら、
隣り合う２つの多角形が共有する頂点の座標は必ず同値になる


それはそれとして、もし >>52 の通りなら、
辺を共有するハーフエッジが互いに同方向を向くかどうかを調べればよくないか？
>>51 を読んでそれくらいは自分の環境に合わせて知恵を働かせて読み替えてほしいのだが
0055デフォルトの名無しさん2012/04/17(火) 10:32:51.84
>>32
だから、「コーダー＝写経する人」ってどんな人達なのか説明しろって
0056デフォルトの名無しさん2012/04/17(火) 10:39:25.73
>>38
どうやってテストするも何も、テストケース毎に引数を与えて戻り値チェックするだけだろ
0057デフォルトの名無しさん2012/04/17(火) 11:30:10.33
>>55
> 「写経」というのが、詳細な設計情報をただ単にコードに落とすというのを指してるとすると、
という前提条件の元で進んでたと思ってたんだがな。
0058デフォルトの名無しさん2012/04/17(火) 11:48:58.24
は？
>>26
>おそらく君が日常的に接しているソフトの大半はその写経で作られてる。
↓
>>31
>コーダってもうWeb業界でしか使わないよ
↓
>>32
>うん、そういう人たちはPGって呼ばれてるね。

PGと呼ばれてる人の定義は？
コーダの定義は？
0059デフォルトの名無しさん2012/04/17(火) 11:53:45.27
>>38
何をやってるのかわからんが、穴が開くかどうかとテストのしづらさにどんな関係があるんだ？
0060デフォルトの名無しさん2012/04/17(火) 21:42:08.00
だからさ、写経の元になる
設計がどんなのか言ってみろって。

たとばクイックソートの設計。
その設計を ”写経” すればコードになるんだろう？（・∀・）ﾆﾔﾆﾔ
0061デフォルトの名無しさん2012/04/17(火) 21:45:52.69
写経ってのはコードをそのまま写すことを言うんだよ。
書いてあるものを全くそのまま写す。

少しでも書き換えたり付け足したり削除したりしたら
本来の意味の（お経の）写経にはならないよね？

つまり何が言いたいのかというと
設計＝コードなのさ。

コーダーっての設計でできたコードを紙に印刷して、
はそのコードをコンピュータにそのまま入力するのが仕事。
0062デフォルトの名無しさん2012/04/17(火) 21:53:56.29
>>58
> PGと呼ばれてる人の定義は？
> コーダの定義は？
遠い昔の話しさ。
昔はコンピュータがものすごく高価で
一人一台無いの当たり前、数時間単位で交代で使っていた。

だからといってコンピュータが使えない時間に遊んでいていいわけなくて
”紙”にコードを手書きしていた。そのコードを書くのがプログラマ。

プログラマだからといってタイピングが速いとは限らないよね。
そう、その紙に書かれたコードをコンピュータに高速で間違いなく入力する人がコーダー

今は、コードを紙に書くなんてことはしないので、コーダーというのは存在しなくなった。
もしコーダーがいる会社があったとしたら、そこのプログラマは手書きでもしてるのか？って
言いたくなっちゃうよ。
0063デフォルトの名無しさん2012/04/17(火) 22:32:40.52
>>54
>辺を共有するハーフエッジが互いに同方向を向くかどうかを調べればよくないか？
その値を出すことは可能なのは解るよ。じゃあそれをどうやってコードに落として自動テストするの？
そこが問題だよ。もうひとつ聞くと、それは式が正しいかであって結果が正しいかは調べられないよね。

http://up3.viploader.net/pc/src/vlpc011111.png
本題でもないけど処理の内容が上手伝わってないようなので
何日持つのか解んないけど画像上げてみた。

左上の三角が辺のめぐり順が正しい場合。
右下の三角が辺のめぐり順が間違ってる場合。
右下の方は解りやすいように、分解度を下げ、
穴が開いた周辺の三角に色を塗っておいたよ。
0064デフォルトの名無しさん2012/04/17(火) 23:22:47.99
>>63
三角形を描画する関数をスタブに置き換えて、三つの頂点を a, b, c として、
・描画済みの辺の集合に ab, bc, ca を追加
・描画済みの辺の集合に ba, cb, ac があればエラー
とするだけでしょ。全然テストしやすい部類に入ると思うけど。
0065デフォルトの名無しさん2012/04/17(火) 23:38:30.23
なるほどね。じゃ式が正しいかじゃなくて描画結果が正しいことはどうやってテストするの。
0066432012/04/17(火) 23:58:51.53
>>63
・前者について

君の言う自動テストというのは、変数 xs を細分化後の三角形リストとして、
リスト内の全ての三角形において正しい順に頂点が並んでいる場合に
isValid (xs) が真となるような関数 isValid を作る事だよな？

ハーフエッジがどういうものかは既に分かっており、
それが有向グラフで表現できることも分かっているんだよな？

細分化後の三角形リストを元にハーフエッジを表現する有向グラフが作れれば、
その有向グラフの全ての辺を調べ、２つのノードを共有する２辺について、
それらが互いに逆向きになっているかどうかを調べることで、
全ての三角形が正しい方向を向いていることを調べられることは分かるよな？
（君の言う >>52 の方が正しければ、互いに同じ向きになっているかを調べる）

そのような方法で isValid 関数が作れることも分かるよな？

で君は「細分化後の三角形リストからハーフエッジを表現する有向グラフを作る方法」
結局のところこれが分からないから教えてほしいと言うことなのか？
0067432012/04/18(水) 00:01:03.67
・後者について

式が正しければ結果は必ず正しいという前提で（信じて）行うのが「テスト」だ
これは分かってるか？

その「式」と「結果」には何が含まれると考えている？
当然、式には「細分化を計算する式」と「レンダリングを計算する式」が、
結果には「細分化された結果」と「レンダリングされた結果」が含まれるはずだが

どうも君は「細分化を計算する式」だけの正しさと、
「レンダリングされた結果」だけを結びつけて
「式が正しいかであって結果が正しいかは調べられない」と言っているように聞こえるが

つまり、レンダリングを計算する式の正しさを検証するテストについて考慮していない
0068デフォルトの名無しさん2012/04/18(水) 00:21:34.94
>>67
>つまり、レンダリングを計算する式の正しさを検証するテストについて考慮していない
その通りだね。あくまでもレンダリング部分は正しいという前提で書いてるよ。

>「レンダリングされた結果」だけを結びつけて
>「式が正しいかであって結果が正しいかは調べられない」と言っているように聞こえる
これもその通り。そもそも>>43さんとの間に式というものに認識の齟齬があるのかも知れない。
今のところ、こちらとしては>>43さんのいう式は回転の向きの計算だと思ってます。
じゃSubdivision関数全体のテストをするにはどうするの？ってのが気になってます。
で、今のところSubdivisionのテスト結果は描画結果が正しいかで判断するしか
無いだろう、別の方法でもあるのかなーという風に思ってます。
0069デフォルトの名無しさん2012/04/18(水) 00:32:04.93
レンダリング部分に問題がない、かつ、面の向きも無関係ならば
あとは細分化した三角形の頂点座標が同じかどうかチェックすれば十分では？
0070デフォルトの名無しさん2012/04/18(水) 00:48:30.84
>>68
結局のところ、何をテストしたいのかはっきりさせればいいのでは。
Subdivision関数を呼び出したときの描画内容をテストしたいのなら、
描画結果の確認をするだろうし、
Subdivision関数自体の動作をテストしたいのなら、描画APIを自前の
ものに入れ替えて、APIに渡される座標値などをチェックするだろうし。
0071432012/04/18(水) 07:34:19.65
>>68
> じゃSubdivision関数全体のテストをするにはどうするの？ってのが気になってます。

君は自分が提起した問題を自分で何か別のものにすり替えていないか？
あるいは本当は何をテストしたいのか、自分でも整理できていないのではないか？

>>38
> 正しい方向で巡らないと穴が開いたりすんだよね。
> こんなのどうやってテストすんだろ。

この通り、テストしたい事柄は「正しい方向で巡っているかどうか」だけだと思ってたが
つまり、三角形を構成する3つの頂点座標が正しい順でリストに入っているかどうか

これであれば >>66 の方法で正しいかどうかを必ずテストできる（効率云々は別の話）

テストしたいことが他にもあるのなら、>>70 の言うようにハッキリさせなさい


それともう一つ言っておくが、ある事柄をテストする場合は、
その事柄が「依存する」他の事柄について完全にバグが無い状態でテストすべきだ
（正しくは、バグが無いことを信じられる、前提にできる状態）
依存する他の事柄にバグがあれば、テスト結果が何によってもたらされたのか分らない
テスト結果を信用することができない

Subdivision関数全体というのが、
どのような場合にどのような結果が出る事を想定したテストの事か知らないが、
それを求めているということは、当然それが依存する他の事柄は全てテストできている
ということなのか

しかし私は、正しい方向で巡っているかどうかすらテストできていない状態で、
Subdivision関数全体とやらが正しくテストできるとは到底思えない
0072デフォルトの名無しさん2012/04/18(水) 10:35:09.35
>>62
だから、今でもコーダーという職種が存在してるってば
Web業界に
0073デフォルトの名無しさん2012/04/18(水) 10:40:46.66
レンダリングの結果が正しいかどうかというのはレンダラー側のテストであって、Subdivision()とは関わりが無い。
Subdivision()が正しく動作しているかどうかの確認項目に、レンダラーに正しく情報を渡しているかどうかが
あるなら、それをチェックできるようにすべき。

上記のSubdivision()が何をしているのかわからないが、「座標を計算し、描画し、何らかの結果をboolで戻す」
関数だとしたら、それは責務が多すぎるのでリファクタリングしてテストしろと思う。
0074デフォルトの名無しさん2012/04/18(水) 10:48:37.97
「小さい穴が開く」かどうかが問題だとわかってるなら、なんでそれを検知する仕組みを入れて
てすとしないんだろ
0075デフォルトの名無しさん2012/04/18(水) 10:52:03.39
呼び出すととprivateなメンバに計算結果を保存するメソッドがあって、その計算結果が
privateなんで正しいかどうかチェックできんわーと言ってるのと同じだな。

観測が必須なのに観測できないコードだからテストできないのなら、観測できるような
設計にしてからテストすればOK。なんも難しいことなんて無い。
0076デフォルトの名無しさん2012/04/18(水) 19:41:28.08
>>70
そうですね。
テスト目的自体は、Subdivision関数が正しい結果をだすか否かを確認し、
この条件での実行は問題ないと証明することです。
別に何が原因でバグが発生したかはどうでもいいといえば、どうでもいいです。

描画関数についてですが、それ自体は、飽くまで結果の確認方法という位置づけです。
貼りつけたコード上では解りませんが、描画部分は仮想関数で、そもそも何を実装するのか
決まってません。確認方法の実装が描画以外の方法でも全く構いません。
1種類に限らず複数の確認方法でも構いません。ただ、確認方法の候補として
今のところ描画を持ち出してるだけです。

>>71
>>74
私が穴が開くって所を引きずったせいで、ややこしくさせてる感じがありますが。
穴が開くのは、「穴が開いたり」と書いたように、飽くまでコーディングミスで起こり得るバグの一例です。
他にもコーディングミスで三角形全体を囲む辺がでこぼこになったりというのもあります。
ただ、あくまでテストなので、正しいか正しくないか2択の結果が得られれば十分だと考えてます。
0077デフォルトの名無しさん2012/04/18(水) 19:56:51.76
>>76
Subdivisionはとりあえず置いといて、
使ってる描画APIは頂点を共有する三角形を複数描画した時に
(うまく頂点を指定しないと)穴が開いたり、
辺がでこぼこになったりするものなのか？

上記の問いに対する答えがYesで、かつ正常に描画されることを確認したいのなら、
描画結果を保存して、理想的な描画結果と比べるしかないだろう。
0078デフォルトの名無しさん2012/04/18(水) 20:05:29.13
>>77
塗りつぶしの処理自体は全く問題有りません。
自分が作った塗りつぶし処理を使う必要もありませんから、
出来合いのライブラリつかってもいいですし。

>描画結果を保存して、理想的な描画結果と比べるしかないだろう。
見比べるんじゃなくGood, Bad、 成否といった形で結果が欲しいんですが。
このスレの趣旨はテストの自動化だと思って今まで質問してきたつもりです。
全てのテスト条件の結果を一枚一枚見比べるというのは昔ながらの方法じゃないですか？
0079デフォルトの名無しさん2012/04/18(水) 20:18:22.69
比べるのも自動化したらいいよ。
0080デフォルトの名無しさん2012/04/18(水) 20:25:51.92
出来合いのライブラリ使えば、穴も開かなくて済むんじゃないの？
0081432012/04/18(水) 21:59:43.74
>>78
本来、描画する方法が正しければ、>>79 の言うように
画像比較「でも」正しく、かつ自動的に Good, Bad でテストできる
その方法を初めに >>43 で言ったはずだ

隣り合う三角形が共有する頂点の座標が同値の場合に、
１ピクセルも穴が開かない「普通の正しい」レンダリングエンジンを使っていれば、
>>43 や >>79 の画像比較「でも」問題なくできる
１ピクセルずつ元画像と比較すれば良いだけだ（プログラム的には至極簡単）

しかし君は、私たちには何故か理由は分らないが、
正しい順で頂点を巡っても穴が開く場合があると主張する

であれば、それはそのレンダリングエンジンに問題があるか、
あるいは共有する頂点の座標が同値でないという不適切な細分化処理をしているか、
このどちらかありえないと私は思う
だから >>79 や >>43 の画像比較でテストするという前提なら、
Subdivision のテストとレンダリングエンジンのテストは分けるべきだ
そして当然レンダリングエンジンのテストの方を先に考えるべき


それとは別の話として、１ピクセルずつでの画像比較ではあまりに処理時間がかかる
というのであれば、Subdivision の方のテストとしては >>66 の方法でテストできる
これも正しく、かつ自動的に Good, Bad でテストできる


私からは２つのテスト方法、画像比較とハーフエッジをの提案したが、
それで不満であれば私が提案できるテスト方法はもうない
（２つの方法の処理速度改良案、あるいは計算機科学的に正しさを証明する方法はあるが）
0082432012/04/18(水) 22:03:43.74
>>81
紛らわしいタイポをしてしまったので訂正する

> であれば、それはそのレンダリングエンジンに問題があるか、
> あるいは共有する頂点の座標が同値でないという不適切な細分化処理をしているか、
> このどちらかありえないと私は思う

このどちらか「しか」ありえないと私は思う
0083デフォルトの名無しさん2012/04/18(水) 22:10:18.02
>>81
>１ピクセルずつ元画像と比較すれば良いだけだ（プログラム的には至極簡単）
ここに関しては異論はありませんよ。これしか方法が無いのかとも思いますが。
0084432012/04/18(水) 22:14:43.03
>>83
> これしか方法が無いのかとも思いますが

確認だが、これしか方法が無いと思うとはどういう意味だ？
画像比較でテストするならば、これしかという意味だよな

まさか、画像比較ではない >>66 の方法は無視するという意味ではないよな？
0085デフォルトの名無しさん2012/04/18(水) 22:16:06.50
そういやprivateメソッドの話で思い出したんだけど、
なんで、オブジェクトに自己内部テストを行う
publicなselftestメソッドを作ろうって話にならないの？

ユニットテストは外部からのテストをするものだから
って意見はわかるんだが、テストをするのが目的であって
外部からテストをすることにこだわる必要ないよね？

オブジェクト自身にprivateなメソッドのテストを行う
selftestメソッドを持たせてもいいと思うんだけど。
つまりオブジェクトには（自分自信の）テストコードが含まれてる。
0086デフォルトの名無しさん2012/04/18(水) 22:26:14.34
>>85
> ユニットテストは外部からのテストをするものだから
> って意見はわかるんだが、テストをするのが目的であって
> 外部からテストをすることにこだわる必要ないよね？

１行目のテストは、インターフェース部分が正しいことを確認するテストですよね

２行目と３行のテストは何が正しいことを確認するテストを意味しているのでしょうか
0087デフォルトの名無しさん2012/04/18(水) 22:35:51.36
>>86
関数を作る時、その関数になったら、小さい関数に分ける。
この時小さい関数は外部から呼ばれることはない。
（作った理由が長いだけだから）

そして長い処理全体を一気にテストするのではなく、
小さく分けた関数ごとにテストを行う。

小さく作って小さくテストしたほうが
バグもみつかりやすいし、修正も楽。

だがこの関数は外部に公開しないものであるため
外部からのテストは相応しくない。
なら内部からテストをすれば良い。

これでいいかい？
0088デフォルトの名無しさん2012/04/18(水) 22:36:20.26
× 関数を作る時、その関数になったら、小さい関数に分ける。
○ 関数を作る時、その関数が長くなったら、小さい関数に分ける。
0089デフォルトの名無しさん2012/04/18(水) 22:40:09.78
実際にハードウェアでは
自己チェックモードを備えているものがあるよね。

インターフェースのチェックではなく
自分自身が壊れていないかチェックする機能
0090デフォルトの名無しさん2012/04/18(水) 23:06:17.71
>>87
つまり、内部でしか使わない関数の正しさをテストするために、
その様な関数をコールして値と結果の整合性をテストする処理が書かれた
publicなselftest関数を作れば、外部からそのselftest関数をコールしてテストできる
という意味でしょうか

それは、何か特別なテスト方法として提案するまでもなく、
必要があれば誰もが普通にやってることなので、
特に作ろうという大きな声が聞かれないだけではないでしょうか
（内部関数をユニットテストしたいと思ってるプログラマなら普通に思いつく）

あるいはもっと簡単に内部関数の中や、それを呼んでる関数内で、
比較演算と printf や assert などを使ってテストを済ませてしまう場合もあります
なぜなら、そもそも長いから小さく分けた程度の重みしかない関数だから

また、最近のオブジェクト指向言語ならば、
クラスのプライベートメンバへ外部からアクセスする手段が用意されているので、
それを使ったテストツールを作る事もできますし
（selftest 関数を作るより、こちらの方がテストターゲットのクラスを弄る必要がなくて良い）

そのような方法を使ってるのかどうかは知りませんが、
最近の VisualStodio はプライベートメンバをユニットテストする方法も提供されてますね
http://msdn.microsoft.com/en-us/library/bb385974.aspx


なので、publicなselftestメソッドを作ろうって話になる（盛り上がる）には、
今ひとつ方法論としてのインパクトに欠けるような気がします
0091デフォルトの名無しさん2012/04/18(水) 23:11:17.02
> クラスのプライベートメンバへ外部からアクセスする手段が用意されているので、
これがいかんのよ。

プライベートはあくまでプライベート。プライベートは内部で仕様が変わる。
本来プライベートなのだから自由に変えていいはず。

そこを外部からテストするのはおかしく、内部からテストをするしかないはずなのだ。

で、なんでselftest関数なのかというと、
個々でばらばらで作るんじゃなくてselftestで統一されてれば
コードを書かずともあとはフレームワークやら何やらが
見つけて勝手にテストしてくれるようになるでしょ？
0092デフォルトの名無しさん2012/04/18(水) 23:11:19.09
>>83
> これしか方法が無いのかとも思いますが。
だって、レンダリングがおかしくなる条件がはっきりしてないんだからしかたない。

これが「xxという条件のときに、レンダリング結果がおかしくなる」とわかっていれば
xxという条件が発生していないかどうかでチェックできるんだけど、一連の書き込み
からは、どうもその条件がはっきりしない(というか、はっきりさせたくない?)わけで。
0093デフォルトの名無しさん2012/04/18(水) 23:21:44.42
>>85
拘束条件(不変表明)が守られているかどうかをチェックするためのI/Fを作って、
呼んでもらうようなことはよくやる。

どちらかというと、テストのためというより異常状態になったときに検知するための
Assertに近い使い方だけど。
0094デフォルトの名無しさん2012/04/18(水) 23:26:04.47
>>91
プライベートがあくまでプライベートと言うなら
publicなselftest関数はあくまでパブリックじゃないの？
「これはselftest関数だから
テストフレームワーク以外から呼ばないでね てへぺろ」
とかドキュメントにでも書いとけば許されるのか？
0095デフォルトの名無しさん2012/04/18(水) 23:31:40.06
>>91
それって、selftest関数自体は外部からテストするような格好でコールされるんですよね

単にselftestという名前を統一的に決めておいて、
テストツールから自動的にこの関数がテスト目的で呼ばれるようにするだけのこと？
0096デフォルトの名無しさん2012/04/18(水) 23:46:47.46
>>95
”誰が”テストをするかを明確にするためのもの。

コードを有るべき場所に置く。
自分のことは自分にしかわからない。
そこがあるべき場所。
0097デフォルトの名無しさん2012/04/18(水) 23:47:10.98
”誰が”テストコードを書くかを明確にするためのもの。
0098デフォルトの名無しさん2012/04/19(木) 00:06:34.69
>>96
selftest関数の意義はわかりましたが、
仕組みや、できる事できない事がまだ今一よく分りません

例えばその小分けした関数が、
それをメンバ持つクラスのプライベートメンバ変数にアクセスしている場合は、
selftest関数を使ってどうやってテストするのでしょうか？

小分けした関数がそのようなタイプだった場合は、
ある環境下でコールされることを想定しているという依存性がありますよね
この関数は内部関数なので、普通のユニットテストをしている状況では、
本来はそのような内部の依存性は全く問題にならないものです
（インターフェース部分の結果さえ正しければ内部は問わないから）

しかし、そのようなタイプの関数をselftest関数でテストするのなら、
同じ環境をわざわざ作る（再現する）必要があると思うのですが、どうでしょうか

他にも、こういうタイプの関数はselftest関数では難しいとか、
こういうタイプの関数ならselftest関数でテストする利点があるとか、
何かあるでしょうか
0099デフォルトの名無しさん2012/04/19(木) 10:24:47.12
>>81
> しかし君は、私たちには何故か理由は分らないが、
> 正しい順で頂点を巡っても穴が開く場合があると主張する

このスレ的には、そこはどうでもいいってことにいい加減気づいてください。
0100デフォルトの名無しさん2012/04/19(木) 10:29:04.61
>>38のコードが糞過ぎて、ほんとイライラするんだが、

>>76
> ただ、あくまでテストなので、正しいか正しくないか2択の結果が得られれば十分だと考えてます。

戻り値boolの意味は、「正しい」「正しくない」で、それをテストしたいのだったら、それぞれのテストケースを
与えて戻り値をチェックすればいいだけのことだろ。

何で穴が開くだの、描画結果がだのという話が出てくるんだ。
0101デフォルトの名無しさん2012/04/19(木) 12:32:44.07
>>100
その話はもう終わってる
0102デフォルトの名無しさん2012/04/19(木) 12:37:59.93
>>98
モックやスタブについて調べろ
君の使ってるプログラム言語で使いやすいものが提供されてるかどうかは知らない

なお、当たり前だが、厳密にはプログラムのテストというものは不可能だ
どれだけコストを妥協して実際に近づけるかという話でしかない
0103デフォルトの名無しさん2012/04/19(木) 13:04:54.61
>>91
テストは往々にしてテスト用のライブラリ等を必要としたりするが、テストを実行したくない人に
その準備を強要するのはいかがなものか。
Debug buildの時だけ有効にすれば良いと言うかもしれないが、そのようにすると、Debug build
できる環境に制限を与えてしまいよろしくない。
どうしてもテストしたければ、非公開クラスとしてくくりだして（そうできる言語・環境は限られる
かもしれないが）テストすれば良いのではないか。
0104デフォルトの名無しさん2012/04/19(木) 13:13:35.15
>>103
3点

魅力が足りない
0105デフォルトの名無しさん2012/04/19(木) 13:24:14.99
>>91
> コードを書かずともあとはフレームワークやら何やらが
> 見つけて勝手にテストしてくれるようになるでしょ？

テスト用フレームワーク使ったことないでしょ。
単に実行してくれるだけじゃ駄目なの。
0106デフォルトの名無しさん2012/04/19(木) 20:13:29.19
>>100
本題と関係ないんで説明しませんでしたが
戻り値は描画処理から返ってくるクリップ範囲の判定結果ですよ
テスト用じゃありません
0107デフォルトの名無しさん2012/04/19(木) 21:25:05.67
>>106
なんで細分化関係の処理と描画関係の処理が仲良く合体してんだよ
さっさと別れさせろよ
0108デフォルトの名無しさん2012/04/19(木) 22:05:04.61
>>107
なんでだよ
あと、どうやって
0109デフォルトの名無しさん2012/04/19(木) 22:13:21.98
>>107
このSubdivisionは描画関係の処理なんですが。
細分化した三角形の描画中、クリップ領域の外に出たか
内側に居るか判定できないと非常に効率や取り扱いが悪いです。
まさか、細分化した座標をコレクションにでも保持しておけというのですか？
0110デフォルトの名無しさん2012/04/19(木) 22:54:05.48
>>109
ふつう細分化（Subdivision）ってのは、トポロジーとジオメトリーの処理

頂点を増やして位置を計算し、頂点間の繋がりを再設定する
どちらも、ラスター空間の制約などとは全く関係ない

あるレベルまで細分化された頂点群を見て、
その一部がラスター空間からはみ出ているかどうかを調べたりする処理は、
Subdivision 関数の中じゃなく、別の所で行った方がいい

ひとつの関数内で意味や役割の異なる複数の処理を行うのは良くない
Subdivision 関数は次のレベルの細分化を行うことに徹するべき

疑似言語で簡単に言えば

ts' = Subdivision (ts)　// 次のレベルの細分化された三角形リストを得る
if (OverSpace (ts')) then ・・・

このように一つの意味の塊毎に関数を独立させ、
別の関数において、それら分けた関数をもう一段抽象度の高い意味で繋げる
0111デフォルトの名無しさん2012/04/19(木) 23:05:50.01
>>110
それすると実行効率が非常に悪くなるんですが。
0112デフォルトの名無しさん2012/04/19(木) 23:07:41.78
すいません。さっきの話はどうでもいいので、引き下げます。
0113デフォルトの名無しさん2012/04/20(金) 11:56:00.31
>>106
テスト用じゃないって、意味がわからないんだが。
戻り値をチェックしなくて、何をチェックするんだ？
0114デフォルトの名無しさん2012/04/20(金) 11:57:51.05
そもそも>>38のコードに、描画に相当するコードが見当たらないんだが、一体どの部分を言ってるんだろう。
0115デフォルトの名無しさん2012/04/20(金) 12:25:47.78
>>113
> 戻り値をチェックしなくて、何をチェックするんだ？
仕様通りに副作用が発生するかをチェックすることは普通にあるけど。
0116デフォルトの名無しさん2012/04/20(金) 12:48:11.08
>>115
そんな話はしてない。
戻り値がテスト用じゃないとかほざいてるので、それに返信したまで。
0117デフォルトの名無しさん2012/04/20(金) 12:53:07.61
>>115
俺（>>107 >>110）も
奴が「戻り値は描画処理から返ってくるクリップ範囲の判定結果」と言ったから、
元のコードを見ないままレスした

元のコードなんか知らん
ぱっと見汚そうなんで詳しく読みたくもない

奴の発言を 100% 信じる
違ってたら奴が全て責任とるだろ
0118デフォルトの名無しさん2012/04/20(金) 12:58:31.91
>>109
> 細分化した三角形の描画中、クリップ領域の外に出たか
> 内側に居るか判定できないと非常に効率や取り扱いが悪いです。

もはや何を聞きたいのかわからん状態だが、何で描画「結果」が必要なんだ。
描画「結果」なんか不要。rendererはstubかmockにしろ。
で、rendererに渡った引数で「リップ領域の外に出たか内側に居るか判定」できるだろ。
0119デフォルトの名無しさん2012/04/20(金) 13:01:48.19
>>Subdivisionの人

このスレは、「テストしにくいコードをテストする方法」なんだから、テストしにくい点があるなら具体的に書け。
今までの書き込みでは、テストしにくい点なんか見当たらないんだが。
0120デフォルトの名無しさん2012/04/20(金) 13:09:35.13
>>109
なんでメソッドを分割しないの？
宗教的制約？
0121デフォルトの名無しさん2012/04/20(金) 13:49:12.46
設計が悪い。

はい、次。
0122デフォルトの名無しさん2012/04/20(金) 13:58:56.18
>>116
戻り値は、再帰の枝刈り用じゃないの？
0123デフォルトの名無しさん2012/04/20(金) 14:11:06.13
>>38のコードの話題する人、名前なりTripなりつけてくれないかな
0124デフォルトの名無しさん2012/04/20(金) 14:16:31.86
そもそも"/ 2"とかしていいんかとか言ってみる
0125デフォルトの名無しさん2012/04/20(金) 15:18:38.30
テストと関係無い話はよそでやってくれないかなぁ
0126デフォルトの名無しさん2012/04/20(金) 22:48:13.10
>>114
テストとあんまり関係なく
どうでもいいのと、文字数が増えるので省略してたんですが
if( !deeps ) return /* 省略 */;
の部分が
if( !deeps )
{
　return target.Shell
　　　　　　(
　　　　　　　　Values( Color( tri_colors ) ),
　　　　　　　　Values( Values( vertices[0] ), Values( vertices[1] ), Values( vertices[2] ) )
　　　　　　);
}
こんな感じで仮想関数の呼び出しになってます。

>>118
スタブは否定してません。
結果が不要といいますが、画像という形である必要はありませんが
結果を出せなければ動作の保証にならないでしょう。

>で、rendererに渡った引数で「リップ領域の外に出たか内側に居るか判定」できるだろ。
できないとは思いませんがrendererが、Subdivision関数でクリップ外にはみ出したか
その他の関数でクリップからはみ出したかどういう形で判断するつもりですか？

>>120
いちいち座標と色をコレクションに格納すると実行効率が下がるからです。

>>119 やりづらいと言ってたのは>>115さんがいってる副作用のテストです。
この話は>>43の方の方法で大体結論が出てるのかなと思いますが。
ただ、ハーフエッジに関しては、テストできる範囲がめぐり順だけでテストの要件にあわないのと、
画像の比較チェックをしてしまえば不要になりそうなので、効果が懐疑的ですが。
0127432012/04/20(金) 22:58:48.68
>>126
> テストの要件にあわない

君がいつ明確にテストの要件を示した？
いろいろなレスの中で曖昧に小出しにしてきたような感が拭えないのだが

とりあえず分りやすく箇条書きにしてくれ


>>38
> こんなのどうやってテストすんだろ。

結局初めのこの「こんなの」というのは何を指していたんだ？

質問文をどう読んでも、「正しい方向で巡っているかどうか」
をテストしたがっているようにしか読み取れないんだが
私の読解力が不足しているのだろうか
0128デフォルトの名無しさん2012/04/20(金) 23:07:38.08
>>127
何度も書いてますが結果を保証することが要件です。
0129デフォルトの名無しさん2012/04/20(金) 23:23:58.25
今更ですが、関数の名前が糞なのは認めます。
本来であればGradientShellとでもすべき名前です。
0130デフォルトの名無しさん2012/04/20(金) 23:24:43.93
たとえばSum(int a, int b)のテストコード書くときに
MinValueからMaxValueまで総当たりしたいってこと？
0131432012/04/20(金) 23:25:58.54
>>128
ハーフエッジではどのような結果が保証できない？
0132デフォルトの名無しさん2012/04/20(金) 23:36:11.69
>>131
　const Util::ConstArray<inner_vector_type&,3>
　　&half_vertices = Values
　　(
　　　vertices[0] + ( vertices[1] - vertices[0] ) / 2,
　　　vertices[1] + ( vertices[2] - vertices[1] ) / 2,
　　　vertices[0] + ( vertices[2] - vertices[0] ) / 2
　　);
　const Util::ConstArray<inner_color_type&,3>
　　&half_colors = Values
　　(
　　　Color( Values( tri_colors[0], tri_colors[1] ) ),
　　　Color( Values( tri_colors[1], tri_colors[2] ) ),
　　　Color( Values( tri_colors[2], tri_colors[0] ) )
　　);
ここでしてるんですが(テンソルに正規化するためにオレオレ関数が多くてすいません)
・分割した際の中点位置が誤っていないこと
・生成した中間色がおかしくなっていないこと
・計算に有限桁数にともなう大きな誤差が発生していないこと

他にも、このコード上では起こりえないですが、
もしコーディングミスが有った場合に備え
特定条件で異常終了しないとか基本的な事柄も色々ありますね。
0133デフォルトの名無しさん2012/04/20(金) 23:42:22.01
テストって「与えたケースに対して想定した動作を返すか」
＝あとでリファクタしたときに動作が変わってないか
を検証するものであって

アルゴリズムが正しいかどうかをテストするのは
「テストコード」のテストとは言わないんじゃないの
0134432012/04/20(金) 23:47:14.64
>>132
> ・分割した際の中点位置が誤っていないこと
> ・生成した中間色がおかしくなっていないこと
> ・計算に有限桁数にともなう大きな誤差が発生していないこと

結局テストしたいのはこれらのことか

今までの一連のレスでこれをテストしたいんだと一言でも言ったか？

君が言うには今回の問題は画像比較で解決できそうとの事だが、
次の質問からは「何をテストしたいのか」を明確に簡潔に言ってくれ


ちなみに、>>133 の言うアルゴリズムが正しいかどうかを保証したいのなら、
式（コード）から正しい結果が得られることを「証明」するしかない

その場合は、C++ や Java なら操作的意味論による構造的帰納法を使うと良い
ただし、いきなり大きなアルゴリズム全体を証明しようとすると挫折するから、
小さく部分問題に分解してからの方が良い
0135432012/04/20(金) 23:51:23.31
>>134
誤解を招きそうだな

> その場合は、C++ や Java なら操作的意味論による構造的帰納法を使うと良い

細分化のようにアルゴリズムが再帰的になっている場合に構造的帰納法が有効
（何でもかんでもこれで証明できるわけではない）

証明したいのではなく、あくまでテストしたのなら、すまんかった
>>134 の後半と >>135 は無視してくれ
0136デフォルトの名無しさん2012/04/20(金) 23:57:10.41
>>134
>> ・分割した際の中点位置が誤っていないこと
>> ・生成した中間色がおかしくなっていないこと
>> ・計算に有限桁数にともなう大きな誤差が発生していないこと

>結局テストしたいのはこれらのことか

若干意味合いが違います。テストしたいのは正しい結果が出ることです。
ここに箇条書きしたのは、ハーフエッジでテストした場合に取りこぼす
可能性がある事で目的の部分ではありません。
正しい結果を出せなければ、なんだろうが誤りとして検出する必要があります。
0137432012/04/21(土) 00:00:44.01
ダメだ、ギブアップ

俺にはもう無理
わけが分らん
0138デフォルトの名無しさん2012/04/21(土) 00:10:59.56
>>134

>君が言うには今回の問題は画像比較で解決できそうとの事だが、
>次の質問からは「何をテストしたいのか」を明確に簡潔に言ってくれ

例えば、2次元のデバイス(RasterLogic target)が与えられ、所定の座標と
所定の色が与えられた場合、>>63 の画像に有った左上の三角形が出る事です。

他にも3次元上のテクスチャーデバイスを与えられ、所定の座標、所定の色が
与えられれば、想定結果とされるイメージ通りのテクスチャーが描画される必要があります。

ようするに、ある条件を指定したとき、想定結果どおりの結果がでるか調べる事です。
0139デフォルトの名無しさん2012/04/21(土) 00:13:57.52
ＴＤＤ知ってるよね
君以外はこのスレでのテストってＴＤＤのテストのことだと思ってるよ

Sum(1, 2)に3が帰ってくることを保証するのがテスト
数学的に1+2=3と証明することじゃない
0140デフォルトの名無しさん2012/04/21(土) 00:17:56.25
>>139
>>43に言ってんの？
0141デフォルトの名無しさん2012/04/21(土) 00:17:57.41
>>139
ＴＤＤ以外のテストもありますが？
0142デフォルトの名無しさん2012/04/21(土) 00:33:00.54
>>139
私の方の話であれば、
Subdivision( 出力先条件, 座標条件, 色条件 ) → 結果 == 想定結果(画像等)
というテストをしたいので別に矛盾はしてないと思いますが。
0143デフォルトの名無しさん2012/04/21(土) 01:16:05.84
で、面倒というだけで技術的課題は何も無いように思うが？
0144デフォルトの名無しさん2012/04/21(土) 01:31:50.01
>>142
テストした条件において、想定結果となる
ということしか示せない。条件が少しでも異なった場合になにが起こっても泣かないこと。
0145デフォルトの名無しさん2012/04/21(土) 01:36:16.40
で、穴が開くとか辺がずれるって話はどうなったんだ？
0146デフォルトの名無しさん2012/04/21(土) 13:47:50.29
証明の話が出てるけど
VDMとかBとかZとかのスレって無いの？
0147デフォルトの名無しさん2012/04/21(土) 14:56:15.83
無い
0148デフォルトの名無しさん2012/04/21(土) 17:50:47.59
>>17
GUIのテストだけども
0149デフォルトの名無しさん2012/04/22(日) 05:04:50.46
質問者が必要な情報をきちんと出さないから、回答者は仮定に対しての答えしか出せず、結果質問者の求める答えが得られないんじゃないか？
0150デフォルトの名無しさん2012/04/22(日) 12:37:26.88
必要な情報をきちんと出せるのなら、
ほとんどの場合その時点で質問の90%は自己解決する

あとはピンポイントで細かい質問を少しして、
こちらもピンポイントでそれに答えるか、
参考文献を紹介して終わり

たいていは至極簡単なやりとりで終わるはずだが、
今までのやりとりを見ていると、>>38 には絶対に無理だと思った

何が必要な情報なのか、そもそも何が知りたいのか、
自分でも頭の整理が全くできていない様子
なんか色々なものをまとめて一発でテストできる方法無いかなと
大雑把に希望を抱いているだけにしか見えない
個々のテスト項目を細かく把握する能力が無い
0151デフォルトの名無しさん2012/04/23(月) 10:57:32.47
>>142
だから、なんでレンダリング結果がないと判定できないんだよ？
0152デフォルトの名無しさん2012/04/23(月) 11:57:48.07
なんでテストがやりづらいと思ってるのか、きちんと文章で表現しろよ。
だんだんうざくなってるよ、君。
0153デフォルトの名無しさん2012/04/23(月) 15:52:55.92
>>142
レンダラーをスタブに置き換えて、レンダラーへの引数を評価するやり方で駄目な理由は？
0154デフォルトの名無しさん2012/04/23(月) 22:25:48.78
まだ続けてたんですね。もう>>43さんの話で終わったと思ってったんですが。
0155デフォルトの名無しさん2012/04/23(月) 22:26:48.55
>>153
既にそれでも構わないと書いてますよ。
0156デフォルトの名無しさん2012/04/24(火) 10:30:37.77
>>155
なんでまだだらだら続けてんの？
0157デフォルトの名無しさん2012/04/24(火) 12:47:25.81
>>156
最初の質問者に対してひとりでも反論や質問があれば、そりゃ応え続けるだろ

対応し続けなければ無責任だ
0158デフォルトの名無しさん2012/04/24(火) 13:04:56.51
>>157
なぜテストしにくいと思ってるのかを明らかにせずに、なんでこのスレに居続けるのってこと
0159デフォルトの名無しさん2012/04/24(火) 19:55:53.53
>>158

>>153 の質問に対して >>155 と応えるために居たんだろ
それ以外の理由が思いつかないのだが

>>153 がログも見ないで質問するから、
>>155 と応えざるを得なくなる

馬鹿な質問しなければ、きっと消えてただろう
0160デフォルトの名無しさん2012/04/25(水) 23:34:22.96
テストしにくい訳じゃないけど
処理に時間がかかるテストの扱いってどうしてる？
0161デフォルトの名無しさん2012/04/25(水) 23:45:47.18
>>160
余程のことが無い限り、工夫してテスト時間を短縮させるような
テストコード案を時間をかけて考えることはしないな
さっさとその時間がかかるテストを開始した方がマシ

また、テストで大事なのは何よりも「正確なこと」
テストコードを凝ってバグを仕込むのは本末転倒だから、危機は近寄らずだ
最初に素直に考えた、時間はかかるが正確なテストコードで妥協する

で、時間かけてテストさせておいて、その間他のことをしてる
0162デフォルトの名無しさん2012/04/25(水) 23:47:59.47
じゃあ次のうるう年まで待つか・・・
0163デフォルトの名無しさん2012/04/25(水) 23:51:06.83
>>162
どういう意味なのか、よく分らないのだが・・・

ギャグ？　それとも何かの皮肉？
0164デフォルトの名無しさん2012/04/26(木) 10:42:24.44
>>160
そういうテストは一般に「スローテスト」と呼ばれている。スローテストは無いにこしたことない。
ググったTop3書いとくから読んでみて。

スローテストの悪夢 | Act as Professional - hiroki.jp by HIROCASTER
http://hiroki.jp/2011/01/17/1486/

スローテストとTDD: プログラマの思索
http://forza.cocolog-nifty.com/blog/2011/01/tdd-b137.html

スローテストを解消する12の方法 | Ryuzee.com
http://www.ryuzee.com/contents/blog/4520

>>161
うちでは、スローテストはCIツールにやらせてる。
失敗したらメールが来る。
0165デフォルトの名無しさん2012/04/26(木) 13:59:09.24
>>163
ギャグであり皮肉
0166デフォルトの名無しさん2012/04/26(木) 14:02:07.38
>>161
とかいう思考停止する奴は、プログラマに向いてないと思うよ。
0167デフォルトの名無しさん2012/04/26(木) 14:17:05.93
>>161
馬鹿じゃ無いの？
他のことなんかしないで、その糞テストコードをまずなんとかしろよ。
0168デフォルトの名無しさん2012/04/26(木) 14:38:43.57
>>166
項目は少ないに越したことはないだろ
0169デフォルトの名無しさん2012/04/26(木) 14:57:31.06
>>168
何の話してるの？
0170デフォルトの名無しさん2012/04/26(木) 20:11:01.43
>>167
ある計算（処理）が正しいことをテストする場合、
明らかに正しいと信じられる方法を用いて計算（処理）する別のものを用意し、
両者の結果を比較するという方法がある

この場合、その別のものは明らかに正しいと確信できるものにするために、
普通は凝った最適化は施さず、また単純なアルゴリズムを用いる
したがって、必然的にテスト対象のものよりも処理時間がかかる

テストでは両者を実行してその結果を比較するので、
結果的にテスト対象単体で実行した時の倍以上の時間がテストにかかる
（実際はテストデータの作成などは共通化できるので単純には言えないが）

元々のテスト対象の計算（処理）が時間がかかるものであれば尚更だ

あなたの言う「糞テストコード」というのは処理時間的に糞だと言うことなのだろう
しかしその代わり、計算（処理）の結果については完全に正しいことが
誰の目にも明らかなコードではある（明らかで無ければテスト結果が信じられない）
そのぶん処理時間がかかるのは致し方がないことだと私は思う
0171デフォルトの名無しさん2012/04/27(金) 09:12:08.04
>>160
テスト=正しい答との比較、で済むような単純なアプリでは自動実行で放置。
テスト=設計の間違い探し、が必要な探索的開発では仕様のテストにバックポート。
0172デフォルトの名無しさん2012/04/27(金) 11:53:33.00
>>170
何で「明らかに正しいと信じられる方法を用いて計算（処理）する別のもの」を毎回実行するんだ？
一回実行して結果を保存して、それと実行結果を比較しろよ。

> あなたの言う「糞テストコード」というのは処理時間的に糞だと言うことなのだろう
いいえ、お前に関しては、仕組みが糞です。

> そのぶん処理時間がかかるのは致し方がないことだと私は思う
という思考停止ぶりも糞だな。
0173デフォルトの名無しさん2012/04/27(金) 12:54:02.46
>>172
結果を保存してと言うが、入力するデータが変わったらどうなる？
0174デフォルトの名無しさん2012/04/27(金) 12:58:00.40
以降、なんやかやで自分は正しい合戦が始まる気がするが、>>164でFAでしょ。
スローテストは無いにこしたことはない。

あと、詳細を明らかにせず「うちではスローテストを解消できないのは○○だからだ」的な
話はやめてね。>>170
0175デフォルトの名無しさん2012/04/27(金) 13:01:03.38
>>173
テストの基本がわかってないなぁ。
基本的に、入力が一緒なら出力も一緒になるようにコード書くの。
実行時に毎回値が変わるリソースはスタブにするとか。

だから100通りの入力データがあれば、100通りの実行結果を保存しておいて、
あとは何度テストしてもテスト対象の実行だけでいいでしょ。
0176デフォルトの名無しさん2012/04/27(金) 13:17:23.13
>>161
> 工夫してテスト時間を短縮させるような
> テストコード案を時間をかけて考えることはしないな

MockやStubとかを使ったことないの？
0177デフォルトの名無しさん2012/04/27(金) 19:35:34.91
ケースバイケースでどっちも正しいんだろうけど

このスレ的には>>164的考えの人が多いのかな？
俺の用途だと>>170のほうがしっくりくることが多い
もちろんどっち側も書いてはいる
0178デフォルトの名無しさん2012/04/27(金) 19:50:08.13
要素が多いとかで時間がかかるなら、そんなのは1時間に1回くらい自動で回せばいい
普段はモックなりスタブなりである程度の値を渡すテストで代用
0179デフォルトの名無しさん2012/04/27(金) 19:55:02.61
>>174
もっともだ、申し訳なかった

私は所謂 QuickCheck 的なテストを想定していた
テストデータを境界値、境界付近、中央付近などで毎回ランダムに生成し
（テスト対象によっては適切なテストのために偏ったランダム値を使うこともある）、
それらのデータを使って両者を比較する

最初に一回だけランダムに生成して、それを何回かのテストで使い回す方法もあるが、
そういう事が有効では無い場合も少なくない

例えば最初のテストで失敗し、その失敗したデータと計算式を見比べて、
なぜ失敗したのか、どこにバグがあったのか調べて、原因を取り除くとする

それをもう一度テストしてみる時、もちろん先ほどと同じデータで
テストがパスすることは大事だが、原因を取り除くと同時に他のバグが入る可能性もある
そのために全く別のランダムデータでも一度はテストしてみる必要がある
（もちろん、その必要が無いほど簡単な修正で済めば、他のテストの必要は無いのだが）

そうすると、結局のところテストの度にランダムなデータを使わざるをえない

というタイプのテストの場合には、元々時間がかかる処理のテストは、
どうしても更に時間がかかることは考慮しておかなければならないと思う
0180デフォルトの名無しさん2012/04/27(金) 21:01:20.48
糞が糞みたいなコード書くと糞みたいな動作しかしない
0181デフォルトの名無しさん2012/04/28(土) 00:02:29.42
と糞が自己紹介しております
0182デフォルトの名無しさん2012/04/29(日) 16:54:08.63
>>179
ランダムテストしかしないところもあるんだな…
0183デフォルトの名無しさん2012/04/29(日) 17:04:56.51
ところっていうかテスト対象の特性によるだろ
それともランダムテスト以上に
有効かつ汎用的な手法でもあるのか？
0184デフォルトの名無しさん2012/04/29(日) 17:28:00.24
>>183
ああ、すまん。
うちのところは全件やるのが当たり前だから。
0185デフォルトの名無しさん2012/04/29(日) 17:31:18.20
>>182
ランダムテストしかしないわけではない

質問が「処理に時間がかかるテストの扱い」だったから、
質問するほど扱いに困るような時間がかかるテストと言ったら、
ランダムテストしか思い浮かばなかった

ランダムじゃ無ければ、それこそ >>175 の言うようにすれば良いわけだし
0186デフォルトの名無しさん2012/05/01(火) 11:41:22.14
>>185
>>1に書かれてるように、このスレは主に「ユニットテストみたいなもの」に関するスレ。
ランダムに入力値を与え、繰り返してストするのはユニットテストの範疇ではないのでスレ違い。

> そうすると、結局のところテストの度にランダムなデータを使わざるをえない
と思い込んでるだけだな、多分。
0187デフォルトの名無しさん2012/05/01(火) 11:44:33.31
>>186
なんで範疇じゃなくなるのかと小一時間
0188デフォルトの名無しさん2012/05/01(火) 11:46:11.77
>>185
> 質問が「処理に時間がかかるテストの扱い」だったから、
> 質問するほど扱いに困るような時間がかかるテストと言ったら、
> ランダムテストしか思い浮かばなかった

>>164のリンク先読んだ？
巷で言われているスローテストとは、何がスローなのかがわかる。
0189デフォルトの名無しさん2012/05/01(火) 11:49:40.24
>>187
ランダムテストというのは、アドホックテストやモンキーテストと同類の、ブラックボックステストの手法。
この手法でしかユニットテストができないというのであれば、それは設計が悪い。
0190デフォルトの名無しさん2012/05/01(火) 11:58:32.67
一連の発言は>>161の人？

だったら、なんか>>161と趣旨が変わってる気がするけど。

>>161
> 余程のことが無い限り、工夫してテスト時間を短縮させるような
> テストコード案を時間をかけて考えることはしないな
> さっさとその時間がかかるテストを開始した方がマシ

これは逆で、よほどのことが無い限りスローテストを放置することはしない、というスタンスが好ましい。
0191デフォルトの名無しさん2012/05/01(火) 12:32:15.36
>>189
>>179 は「テストデータを境界値、境界付近、中央付近などで毎回ランダムに生成し」って
書いてるから、どっちかって言うとユニットテストを抜粋しているイメージで書いてるんじゃね？

まあ、本当のところは >>179 に聞かないとわからんけど。
0192デフォルトの名無しさん2012/05/01(火) 12:38:02.42
なぜ毎回ランダムに生成するのかわからん。
境界値、境界付近、中央付近の値をすべてテストすればいいのではないか。
0193161, 179 その他2012/05/01(火) 12:45:22.03
>>186
申し訳ない
完全に >>1 が頭から抜けていた

確かにスレチであり、質問者にとっては意味が無かった
あと、スレチにも関わらずレスしてくれたみんなには、ありがとうと言いたい
ランダムテストの話だったと仮定しても、皆さんの意見を聞いていると、
どうもまだまだ私の経験不足のようなので精進してくる
（特に >>190 （やその他の人）の意見は私と真逆なので、もっと考えてみる）

>>191
いや、完全に QuickCheck のようなランダムテストを想定していた
ただ、それでも私の所では境界値や中央付近などの値を狙って
ランダムにテストデータを生成する仕組みを作っている（使っている）
そういうのがランダムテストだと思い込んでた

全てのレスに個別に返答できないので申し訳ないが、
私の考え方が間違っているっぽいので、反論はしっかり受け止めたい
0194デフォルトの名無しさん2012/05/01(火) 13:16:06.58
>>192
完全に同意。
ユニットテストでは、同値分割するとか、直交表を使ってケースを減らすとかして、「有限・少数の決められた(複数の)値」で
期待した結果が出るのを確認すれば十分。

>>193
最後みたいだから言うが、句読点ちゃんと打て馬鹿。
0195デフォルトの名無しさん2012/05/01(火) 13:19:50.89
1、2行ならともかく、がっつり長文書く時でも句読点打たない奴結構見るが、流行ってたりするのか？
0196デフォルトの名無しさん2012/05/01(火) 13:27:15.51
句点打たない奴が多いのは、携帯メール常用で、句点打つ習慣が無い奴が増えたからではないかと推察。
0197デフォルトの名無しさん2012/05/01(火) 13:28:27.83
ユニットテストは、
・誰もが
・短時間で
・繰り返し
実行できるものをめざすのが良いという認識が共有されてないな。
0198デフォルトの名無しさん2012/05/01(火) 13:42:13.01
なんか変な流れだな
ユニットテストは結合テストと対になる概念であって
ホワイトボックステストでもブラックボックステストでもいいだろ

そりゃホワイトボックステストができるならその方がいいだろうけどさ
設計が悪いで済ませるのは横着
0199デフォルトの名無しさん2012/05/01(火) 13:46:35.61
>>198
見てると前提や概念が人によって違いそうだからそこらへんを決め付けるなら出展付で頼む
0200デフォルトの名無しさん2012/05/01(火) 13:56:12.96
>>198
普通はユニットテストは開発者が自分で実行するテストで、ホワイトボックスで行うのが普通。
ごくまれに、「普通の」手法でユニットテストができないこともあるかもしれないが、
そんな特殊な話をしても建設的じゃないよ。

> そりゃホワイトボックステストができるならその方がいいだろうけどさ
> 設計が悪いで済ませるのは横着
ごく普通に起こり得る、ユニットテストの範囲のテストでホワイトボックステストが行えないような例を挙げてみ？
自分が今書いた/これから書くコードをテストするユニットテストで、ホワイトボックスでテストできない例なんか
そうそう無いと思うけど。
0201デフォルトの名無しさん2012/05/01(火) 13:57:25.34
>>198
書き忘れたけど、C0カバレッジとかC1カバレッジというのがなんなのか知ってる？
知らなきゃgoogleへgo。
0202デフォルトの名無しさん2012/05/01(火) 14:11:54.46
例えば
long add(long a, long b)
という関数があったときに、オーバーフローが無い範囲を引数の定義域だとして、
if (a == 1234567 && b == 987654) {
return 0;
}
というバグがあるとしたら、ランダムテストはほぼ無力だよ。

ざっくり計算すると、ランダムテストでこのバグを検出できる確率は、1/2^32*1/2^32≒1/10^19で、
1秒間に10億通り(10^10)テストできたとして、検出するには10^9秒必要。つまり、10^9秒≒31年かかる。
だから、ユニットテストではブラックボックスの手法では駄目で、ホワイトボックスでやる。
02031982012/05/01(火) 14:25:18.06
>>202
ランダムテストに完全性求めるのがそもそも間違ってる
それでランダムテストが駄目だという結論にはならない

a == 1234567 && b == 987654をテストケースに入れればよいだけ

どうやってa == 1234567 && b == 987654を探してくるかが分からないなら
ホワイトボックステストでこのバグを見つけるのは
ブラックボックステストより困難だと思うがいかが？
0204デフォルトの名無しさん2012/05/01(火) 14:33:00.27
>>203
全然理解してないな。
ユニットテストはブラックボックステストではやらずにホワイトボックスでやりましょう、
ランダムテストでも良いとか言ってる人いるけど、>>202のように全然駄目だよ、という説明なのに。
0205デフォルトの名無しさん2012/05/01(火) 14:36:37.79
>>203
何の本読んでソフトウェアテストの勉強したのか教えてくれる？
0206デフォルトの名無しさん2012/05/01(火) 14:40:05.21
ホワイトボックステストがどんなテストなのか知らないと見た
0207デフォルトの名無しさん2012/05/01(火) 14:48:05.80
ほんと変な流れだよ。

これこれこういうときにテストしにくいんだけど、みんなはどうしてる？
↓
それはこうすればいいじゃないかな。

的な流れが建設的な会話だと思うんだが。
02081982012/05/01(火) 14:48:48.99
言っとくけど「ランダムテストでもいい」じゃなくて
ブラックボックステストじゃないと事実上対応できないケースもある
そのケースは言うほど「特殊な話」ではないと思っている（これは個人的感想）
だから
ブラックボックステストはユニットテストに適用できない、すべきでない
という論調はおかしいと言いたい
02091982012/05/01(火) 15:02:03.87
じゃあ素直な気持ちで

double型(IEEE 754)の2つの数値の掛け算をする関数
double mul(double a, double b)
{
return a*b;
}
をテストする場合どんなテストケースを与えるか？
コードに分岐がないから条件網羅も命令網羅も簡単だがどうだろうか
02101982012/05/01(火) 15:05:24.42
くどくてすまんが
仕様が不明確とか不十分とかそいういう感想も込みで考えて
0211デフォルトの名無しさん2012/05/01(火) 15:05:26.20
>>209
ホワイトボックステストでできるコードの話題はどうでもいい。
ブラックボックステストじゃないと事実上対応できないケースの話をしてよ。
0212デフォルトの名無しさん2012/05/01(火) 15:06:12.00
それと、>>205の回答もよろしく。
テストド素人の相手をしても時間の無駄だし。
0213デフォルトの名無しさん2012/05/01(火) 15:23:51.48
何だろう。
言語仕様とか、アセンブリレベルの精度か何かをテストしたいとかいうことなのかな。
0214デフォルトの名無しさん2012/05/01(火) 15:26:52.15
>>209
えっと、それのどこがホワイトテストでテストしづらいの？
02151982012/05/01(火) 15:39:08.85
>>209は純粋にみんながどういうことを考えるかが知りたいだけで
自分の主張の正当性だとかを示すつもりじゃないのであしからず
答えたくなければスルーしてくださいな

個人的な回答としては
a*bがIEEE 754に従う前提で
適当なa, bの組1つを入力した場合をテストすれば十分

でも一方をゼロにするとかNaNにするとか
交換則が成立するかテストするとか
ランダムな値をテストするという姿勢は悪くないと思う

スレチだというならa*bをもっと複雑な関数に書き換えるけど
聞きたいことは同じ
0216デフォルトの名無しさん2012/05/01(火) 15:44:15.16
>>215
> でも一方をゼロにするとかNaNにするとか
> 交換則が成立するかテストするとか
> ランダムな値をテストするという姿勢は悪くないと思う

これのどこがランダムな値のテストなの？
決められた値を引数にして、戻り値をチェックするホワイトぼっくつてすとでしょ。
02171982012/05/01(火) 15:47:48.22
>> 212
本はむか～し情報処理試験のときに参考書読んだくらい
あとは*unitとかのドキュメントとかネット情報くらい
テストド素人なので無理して相手しなくても

>>211
業務系だとあまりないかも知れない
純粋な数値計算だとよくあると思うんだが
分かりやすい例なら任意の大きさの行列の演算とか
（ホワイトボックステストできないとは言ってないよ）

上の方で出てきた三角形の分割がどうたらこうたらも該当しそう
（結局要求仕様が不明確で何が言いたかったのかようわからんけど）

出力が満たす必要条件は明確だが十分条件はよく考えないと分からない
あるいは十分条件を導くロジックがテスト対象より複雑になるとかないだろうか
そういう分野はテストじゃなくて形式手法に期待しているがまだまだ

>>216
自分が長文書いてるのはすまんと思うが
ちょっとは過去のレスも読んでくれよ
0218デフォルトの名無しさん2012/05/01(火) 15:52:40.58
>>217
> 分かりやすい例なら任意の大きさの行列の演算とか
> （ホワイトボックステストできないとは言ってないよ）

だーかーらー、なんでこれがホワイトボックステストでテストできないんだよ？
0219デフォルトの名無しさん2012/05/01(火) 15:53:02.23
>>209

assert( 0 == mul( 0, 0 ) );

double half = sqrt( DBL_MIN ): // sqrtはテスト済みとする
assert( DBL_MIN == mul( half, half ) );
assert( DBL_MIN == mul( -half, -half ) );
assert( -DBL_MIN == mul( -half, half ) );
assert( -DBL_MIN == mul( half, -half ) );

double half = sqrt( DBL_MAX ): // sqrtはテスト済みとする
assert( DBL_MAX == mul( half, half ) );
assert( DBL_MAX == mul( -half, -half ) );
assert( -DBL_MAX == mul( -half, half ) );
assert( -DBL_MAX == mul( half, -half ) );
0220デフォルトの名無しさん2012/05/01(火) 15:54:02.73
>>217
え、テストド素人な上にお前以外が一体何を言わんとしてるのかも理解できないのに、
>>198みたいな断言しちゃったわけ？
0221デフォルトの名無しさん2012/05/01(火) 15:58:24.01
>>219
それはやりすぎ
0222デフォルトの名無しさん2012/05/01(火) 16:04:56.30
>>221
境界値テストぐらい普通じゃね？
02231982012/05/01(火) 16:06:26.78
>>218
単純に組み合わせ爆発とか充足可能性問題という観点で

ところで
>>216
の言うようにそれがホワイトボックステストだったのなら
私の勘違いです
すみませんでした

>>219
平方根を使うという発想は素直に面白い
DBL_MINの方に一抹の不安を覚えるが
0224デフォルトの名無しさん2012/05/01(火) 16:09:16.30
>>223
そもそも、テストケースが先にあって、関数をそれに合わせなきゃいけない。
DBL_MINでこけるなら、関数の方を直さなきゃいけない。
0225デフォルトの名無しさん2012/05/01(火) 16:15:30.90
>>228
> 単純に組み合わせ爆発とか充足可能性問題という観点で
なんで組み合わせが爆発するのかわからん。
組み合わせを網羅しないとユニットテストができないというのなら、それは設計が悪い。
int add(int a, int b)
でも、事実上組み合わせ爆発してるけど、これ、ホワイトボックステストでユニットテストできないの？

> の言うようにそれがホワイトボックステストだったのなら
> 私の勘違いです
まず、0やNaNやINFINITなどの数え上げられる具体的な値という点で、ランダムでは無い。
上の方で言ってたランダムテストは、
while (1..N) {
v1 = rand();
v2 = rand();
actual_val = target_method(v1, v2);
expected_val = another_method(v1, v2);
assert(actual_val == expected_val);
}
みたいなテスト（だと俺は理解した）。
0226デフォルトの名無しさん2012/05/01(火) 16:18:33.27
>>170
>ある計算（処理）が正しいことをテストする場合
これ以外のテストって何よ？
耐久テスト？
耐久テストでも、指定の負荷までは正しく処理できるって
テストだから、正しいことをテストする事には変わりないよな。
0227デフォルトの名無しさん2012/05/01(火) 16:26:03.69
>>225
想定ケースを(数学上の)関数をなぞる様に定点的に作れば、
ある程度、テストとしての信頼度を保てる。
もし、完全なテストをしたいなら、全ての入力値と、全ての想定結果を並べればいい。
なに、-INT_MAX ～ INT_MAX　になる引数全ての組み合わせをテストするだけだろ、
1日テスト走らせとけば終わる。もし本当にやるとしても、関数デバッグの最後でやりゃいい。
02281982012/05/01(火) 16:29:05.23
>>215
は
・一方をゼロにするとかNaNにする
・交換則が成立するかテストする
・ランダムな値をテストする
という姿勢は悪くないと思う

って意味だった
この点については曖昧で申し訳ない
だがやっぱり（ゼロとかNaNは自分でも判断に迷うが）
ブラックボックステストだと理解しているんだが

あと分かりやすい表現として組み合わせ爆発という言葉を使ったけど
線形時間で解けるとしても
1日とか一か月とかそれ以上ってなるような場合も含めて考えている
0229デフォルトの名無しさん2012/05/01(火) 16:33:28.85
・ブラックボックステスト　・・・　使用を満たしているかの検査
・ホワイトボックステスト　・・・　想定どおりの処理フローを通っているかの検査
0230デフォルトの名無しさん2012/05/01(火) 16:40:38.34
ホワイトボックスなんてassert貼っときゃいいんだろ
0231デフォルトの名無しさん2012/05/01(火) 17:08:39.49
>>227
> なに、-INT_MAX ～ INT_MAX　になる引数全ての組み合わせをテストするだけだろ、
> 1日テスト走らせとけば終わる。もし本当にやるとしても、関数デバッグの最後でやりゃいい。

だから、long add(long a, long b)程度の関数でも、引数の組み合わせを現実時間で網羅するのはできない。
1日で終わるって、1秒あたりどれくらいのケースをさばける想定なんだ？

>>228
> ・ランダムな値をテストする
> という姿勢は悪くないと思う

いいや、悪いね。ユニットテストでランダムな値でテストする理由が無い。
ランダムな値のテストをどうしてもしたいなら、ユニットテスト以降でどうぞ。

つか、体系的なテスト手法を勉強したことがないんだろ？
何冊か本を買って勉強しなよ。
0232デフォルトの名無しさん2012/05/01(火) 17:11:20.21
>>228
> だがやっぱり（ゼロとかNaNは自分でも判断に迷うが）
> ブラックボックステストだと理解しているんだが

"black box test is"
でググれ馬鹿。
0233デフォルトの名無しさん2012/05/01(火) 17:24:14.06
いいかげん、テストしにくいコードの話をしようぜ。
0234デフォルトの名無しさん2012/05/01(火) 17:29:27.42
>>197までは全然変な流れじゃ無かったのに、>>198から流れが変になったｗ
0235デフォルトの名無しさん2012/05/01(火) 17:34:17.27
>>222
ライブラリを第三者がブラックボックステストする場合なら普通。
0236デフォルトの名無しさん2012/05/01(火) 18:10:42.68
100回試行するのか1000回試行するのかわからないけど、ランダムな値を使ったテストが有効で、
なおかつその実行時間が0.1秒未満なら（できるなら10ms未満）、ユニットテストでやってもいいかな。

ただ、本当に有効な場合にのみ実行すべきで、「いつでもランダムテストを追加すればテストの
信頼性が増す」という思考停止は良くない。
0237デフォルトの名無しさん2012/05/01(火) 18:13:23.61
0.1秒未満というのは厳しいと思うかもしれないが、ランダムテストが100個増えればテスト実行時間が
10秒増え、頻繁なテストスィートの実行のやる気をそぐ。
個人的には、100個のテストが1秒未満じゃ無いと嫌だ。
0238デフォルトの名無しさん2012/05/01(火) 18:34:09.67
試行回数が多いのが遅くなる原因で
ランダムであるかはあまり関係ないということを
念のためお忘れなく

やる気まで含めると費用対効果の評価は個人差が出るので
試行回数の決定はなかなか難しい
そもそもテストの実行回数が人によってだいぶ違う
0239デフォルトの名無しさん2012/05/01(火) 18:41:43.24
何回もって、デバッグ中は境界値テストだけでいいだろ。
時間の掛かるテストはほぼ問題ないという最終段階ですりゃいいだけ。
せいぜい3回が限度。4回も5回も時間の掛かるテストしなきゃならんほどミスするやつは
プログラマーやめりゃいい。
0240デフォルトの名無しさん2012/05/01(火) 23:56:05.42
今も有るのか知らんけど、情報処理試験に出てきた「バグ埋め込み法」ってなんやねん。
ググっても試験問題しか出てこんぞ
0241デフォルトの名無しさん2012/05/02(水) 00:11:24.75
>>240
問題読まんと何ともきいえん
0242デフォルトの名無しさん2012/05/02(水) 00:17:53.09
>>240
> ググっても試験問題しか出てこんぞ

「バグ埋込み法」でググルと、解説付きのページがトップにでてくるんだが…
http://itstudyblog.blog57.fc2.com/blog-entry-60.html

| バグ埋込み法は，捕獲・再捕獲法とも呼ばれ，故意に複数のバグをプログラムに埋め込み，
| この存在を知らないテストチームがテストをし，その結果に基づいて潜在バグを推定する方法
| である。バグ埋込み法による潜在バグの推定は，埋込みバグと潜在バグの発見率は同じで
| あるという仮定のもとに行われる。

この説明読んでもわからないと言うなら、プログラム関係の仕事に付かない方がいいと思う。
0243デフォルトの名無しさん2012/05/02(水) 00:22:16.71
>>242の読解力のなさの方が
プログラム以前に社会人として致命的に思えるが
0244デフォルトの名無しさん2012/05/02(水) 00:24:58.26
>>243
マジでどうおかしいか指摘してくれ。
どうみても、「バグ埋込み法」について聞いているとしか、読解できなかったんだが。
0245デフォルトの名無しさん2012/05/02(水) 00:27:42.22
>>243
書いた本人乙
>>240の文章力が稚拙すぎるだけ
0246デフォルトの名無しさん2012/05/02(水) 00:32:38.90
>>242
どういう方法かを聞いてんじゃないんだよ
試験問題上以外で実在してんのかっつうこと聞いてんだよ
0247デフォルトの名無しさん2012/05/02(水) 00:36:21.23
>>244
お前が持ってきたページも試験問題だろうが
>>240は試験問題しか出てこないと言ってる時点で内容は知っていて
すくなくとも内容のことを言いたい理由じゃないことぐらい解るだろ
0248デフォルトの名無しさん2012/05/02(水) 00:38:38.42
>>246>>247
日本語の勉強やりなおした方がいいな
0249デフォルトの名無しさん2012/05/02(水) 00:41:58.68
表現力が拙いのに偉そうにオレはこう言ったんだよ！ 君に答えると
現実にあるよ。その名で皆が皆呼ぶかまでは知らんが
0250デフォルトの名無しさん2012/05/02(水) 00:46:04.94
ヤベぇ本格的なコミュ障がいる
0251デフォルトの名無しさん2012/05/02(水) 00:47:57.25
なんやねん
みたいなど田舎の方言つかうから悪い
0252デフォルトの名無しさん2012/05/02(水) 00:49:00.00
>>249
>現実にあるよ。
具体的に。
0253デフォルトの名無しさん2012/05/02(水) 00:49:02.61
>>240の文は稚拙というよりあいまいさだな。
>>242もそのあいまいさを無視して断定的な解釈をした。

曖昧な表現/きめつけ
どちらもバグの温床
0254デフォルトの名無しさん2012/05/02(水) 00:49:35.35
>>249
> 現実にあるよ。

実際にやってるってこと？

原理的にはいい方法と思うけど、「埋込みバグと潜在バグの発見率は同じ」ぐらいに
するのが結構難しいので、面倒な割には効果がでないようなことを聞いたことがあるし、
俺の回りで実際にやってるのは見た事がない。

それなりにきちんと運用できてるなら、凄いと思う。
0255デフォルトの名無しさん2012/05/02(水) 00:50:57.10
>>252
前の現場とか、前の前の前の現場とか
0256デフォルトの名無しさん2012/05/02(水) 00:51:44.39
>>254
試験問題以外で、具体的に手法を記述、または紹介した資料はないのか。
0257デフォルトの名無しさん2012/05/02(水) 00:52:03.93
>>254
そこまで精密な数値とかは期待してない

最低限これらが拾われないようじゃ、テストがザルだから不味いよね？判定に使う位かな
0258デフォルトの名無しさん2012/05/02(水) 00:55:11.00
うっかりバグを混入させた時の言い訳に使えるな！
0259デフォルトの名無しさん2012/05/02(水) 00:57:47.73
>>257
「精密な」数値以前に定性的な判断しかして無いな
0260デフォルトの名無しさん2012/05/02(水) 00:59:36.57
>>256
ウィキペディアの用語でググればいんでねーの？
ttp://en.wikipedia.org/wiki/Software_testing_controversies

Bugs can also be placed into code on purpose,
and the number of bugs that have not been found can be predicted based on the percentage of intentionally placed bugs that were found.
The problem is that it assumes that the intentional bugs are the same type of bug as the unintentional ones.
0261デフォルトの名無しさん2012/05/02(水) 01:00:41.42
>>253
>>>240の文は稚拙というよりあいまいさだな。

あいまい？

・今も有るのか知らないけど、情報処理試験に出てきた「バグ埋め込み法」ってどういうものですか。

以外の解釈プリーズ

>>256
大昔に、なんかの雑誌で読んだ記憶がある。
多分、どこかの論文かなんかに載っていたものを紹介していたとと思うけど、さすがに詳細は覚えて
ない。

>>257
なるほどね。
そうは言っても、開発者以外にコードがそれなりに理解できる人 (でないと埋め込めないよね？) が、
ちゃんといる組織かぁ、ちょっと羨ましいな。
0262デフォルトの名無しさん2012/05/02(水) 01:01:26.57
>>259
テストチーム自体の品質がわからんから、大雑把にでも把握しとけば後々色々と捗る
0263デフォルトの名無しさん2012/05/02(水) 01:03:17.20
>>261は話しかけるとめんどくさそうなのでスルーで
0264デフォルトの名無しさん2012/05/02(水) 01:04:29.48
>>261
いや、開発者(つーか俺)がバグを埋め込むんだよ
それらのバグが全部発見されれば、QAチーム(テストチーム)は最低限の及第点はクリアしてる
安心して任せられる
一つも発見されないとしたら、マネジメントに働きかける必要があるサイン
0265デフォルトの名無しさん2012/05/02(水) 01:16:34.97
人を試すようなやり方は
うまく振る舞わないと軋轢を生みそうだな
まぁ既にあるからいいって場合もあるか？
0266デフォルトの名無しさん2012/05/02(水) 01:18:24.09
>>264
ああなるほど、QA 自体のテストね。
でもそれってテスト期間長くならない？
見つけても、見つけられなくても、埋め込んだバグはつぶして再度テストしないと
いけないと思うんだが…

あと、>>265 も言ってるように、QA との人間関係の問題も出そうだし。

>>263
うん、君にはちょっと難しい話だから、スルーしててね。(w
0267デフォルトの名無しさん2012/05/02(水) 01:28:49.40
>>265>>266
軋轢は指摘通り。
トップダウンで、わざと埋め込んだから見つけてね！みたくやっとかないと危ない。
それか、意図的なバグでも自分のミスってことにしとくか。
権限大きいロールなら前者、権限少なければ後者。
後者をやる必要があると感じるのは、例えば、新人をテスト要員に充ててるよーなプロジェクト。
0268デフォルトの名無しさん2012/05/02(水) 01:31:02.49
あと、テスト期間への悪影響はないと思ってる。
というのも、一定期間にテストで見つけられたバグを→全部潰して→またテストして貰う
っていうバッチちっくなテストプロセスだったから。
全く違うテストプロセスなら長くなるケースもあるかもしれんけど。
0269デフォルトの名無しさん2012/05/02(水) 01:58:48.98
>>267-268
なるほど、とてもうちでは採用できないけど、そういうことやってるところもあるんだと
参考になった。ありがとう。
0270デフォルトの名無しさん2012/05/02(水) 02:13:10.33
以上、自演を終わります
0271デフォルトの名無しさん2012/05/02(水) 10:42:43.45
>>256
capture-recaptureでググれ
0272デフォルトの名無しさん2012/05/02(水) 10:44:40.41
キーワードは
software testring capture-recapture
の方が良かった。
0273デフォルトの名無しさん2012/05/02(水) 13:35:03.22
256じゃないが㌧

Bebugging
Fault seeding
Fault injection
Mutation testing

とか色々呼び方あるのな
0274デフォルトの名無しさん2012/05/02(水) 13:35:49.64
>>238
テストの実行回数については、スローテストが無く、今やってるクラスや関連クラスのテスト全部を
実行しても数秒で終わるなら、ファイルのセーブ単位やコミット前にテストを実行する気になる。
その結果、頻繁にテストが行われるようになり、どこかが壊れれば早い段階でわかるようになる。
0275デフォルトの名無しさん2012/05/02(水) 14:15:00.60
ユニットテスト、に対する認識の違いが、人により思いの外大きいというのがここまで読んだ感想。
0276デフォルトの名無しさん2012/05/02(水) 14:50:26.90
まずTDDやBDDを導入しているか否かで全然違うな

ブラックボックステスト否定派はTDDやBDD全否定だしな

TDDやBDDでも実装に入ってからは
実装に応じてテストも柔軟に変えていくべきだと思うが
基本はブラックボックステストだ
0277デフォルトの名無しさん2012/05/02(水) 15:26:29.21
>>276
> ブラックボックステスト否定派はTDDやBDD全否定だしな

そんなこといってる奴いるか？仮想的じゃないの？
0278デフォルトの名無しさん2012/05/02(水) 15:56:36.45
TDDやBDDを能動的に否定している奴はいないな
思想的に相性が悪そうな奴はいそうだな
0279デフォルトの名無しさん2012/05/02(水) 16:24:09.87
このスレの話なのか、お前の周りの話なのかはっきりしてくれ
0280デフォルトの名無しさん2012/05/02(水) 16:37:39.47
TDD、BDD否定派ならわかるが、ブラックボックステスト否定派なんかいるのか？
0281デフォルトの名無しさん2012/05/02(水) 16:40:49.90
>>280
いることにしないと（または、いないことにしないと）話ができない人ならいる
0282デフォルトの名無しさん2012/05/02(水) 16:57:00.11
>>204あたりの字面だけ捉えると
ブラックボックステストは駄目だよ！ランダムテストは論外だよ！
と言っているように読める
これらが>>198の自演ならブラックボックステスト否定派は幻想
0283デフォルトの名無しさん2012/05/02(水) 17:15:26.90
その話は、ユニットテストをブラックボックス的手法だけで行うと、>>202のようなバグは検出できないよねってことであって、
TDD/BDDを否定してるとは思えないが。
自分が書いた実コードがそこにあるんだから、ホワイトボックスでテストしましょうぐらいの話でしょ。
0284デフォルトの名無しさん2012/05/02(水) 17:16:41.76
というか、TDD/BDD否定派と遊びたいならTDDスレ行きなよ。そこにはいるから。
今は死にスレと化してるが。
0285デフォルトの名無しさん2012/05/02(水) 17:24:33.91
つか、なんでランダムテストにこだわってんだよ。
TDD/BDD派ならなおさらランダムテストなんかしようとは思わないだろ。
0286デフォルトの名無しさん2012/05/02(水) 17:26:35.76
TDDはともかくBDDはユニットテストじゃ無いしー的な
0287デフォルトの名無しさん2012/05/02(水) 17:35:46.20
QuickCheckとは何だったのか

ちょっと古いけど
ttp://madscientist.jp/~ikegami/diary/20060906.html
> プログラマが思い付くテストインスタンスはテストに合格するに「決まっている」。
ランダムテストの是非は別としてこの指摘は言いえて妙だな
感心しちゃいけないんだが
0288デフォルトの名無しさん2012/05/02(水) 17:36:21.70
TDDは開発手法であって、テストでもないし品質を担保するものでもありません。
0289デフォルトの名無しさん2012/05/02(水) 17:42:09.51
>>275に戻る
0290デフォルトの名無しさん2012/05/02(水) 17:45:02.15
>>287
プログラマが思い付くテストインスタンスはテストに合格するに「決まっている」。
↓
合格するに決まってるなら、実行しなくてもいいよね。
↓
実行しなくてもいいならテストコードなんか書かなくていいよね。
↓
テストなんかしない。
0291デフォルトの名無しさん2012/05/02(水) 17:51:08.09
> 実行しなくてもいいならテストコードなんか書かなくていいよね。
テストコードが仕様や実装の挙動を明確化する（かもしれない）
という観点では飛べない翼にも意味はあるさ的な

まあ寝ぼけたこと言ってないで有意義なテストをしろって話だが
0292デフォルトの名無しさん2012/05/02(水) 17:52:27.04
うんうん、どんなものもランダムテストでテストすればいいよ
0293デフォルトの名無しさん2012/05/02(水) 17:53:53.35
この人達、リファクタリングしないのかな
それとも、テストが無い状態でえいやってやってるのかな
0294デフォルトの名無しさん2012/05/02(水) 17:55:57.71
XP厨とかTDD厨とかいろんな言葉ができてきたが、新たに「ランダムテスト厨」をそれらに追加しようぜ
0295デフォルトの名無しさん2012/05/02(水) 18:01:25.01
まぁまぁ。
テストしにくいコードに対して、ランダムテストが有効な場面はあると思うよ。
ただ、俺が疑問なのは、
int ret = foo(some_args)
という関数をテストするときに、引数にランダムな値を与えるとして、期待結果はどうやって得るんだ？
上の方で言われてたみたいに、別の手段でそれを取得するのか？
0296デフォルトの名無しさん2012/05/02(水) 18:15:32.97
戻り値を期待結果と比較するのだけがテストじゃないよ

基本は不偏条件(Invariants)や事後条件(Post-Conditions)をチェックする
例えば仕様上偶数が返ってくるのに奇数が返ってきたらバグがある
期待結果が分かる場合はこの特殊例
そのために別の実装と比較するのも一手法

エラーや例外が発生しないこと（あるいは発生すること）は
戻り値を見なくても確認できる
0297デフォルトの名無しさん2012/05/02(水) 18:18:55.95
s/不偏条件/不変条件/
意味的には同じだが検索するときを考えて訂正
0298デフォルトの名無しさん2012/05/02(水) 18:26:16.02
やっぱランダムテスト厨は言うことが違うｗ
0299デフォルトの名無しさん2012/05/02(水) 18:31:01.17
馬鹿か
当たり前のことを書いたらレスもらえないだろ
0300デフォルトの名無しさん2012/05/02(水) 18:31:21.48
>>296
やっぱ納得できんな。
int ret = foo(1, 2, 3, 4, 5);
assert(ret == 15);
の方が優れてると思う（ユニットテストでは）。

テストしにくい、ランダムテストが有効な例を挙げてくれれば納得できると思うんだけど。
ちなみに、<<287のリンク先の例は、全く同意できない。
0301デフォルトの名無しさん2012/05/02(水) 18:37:14.56
機械学習のコードをテストしたときは
ランダムにデータを生成して、学習が進むこと（エラーが下がる等）をチェックした
これは一種のランダムテストだろう
0302デフォルトの名無しさん2012/05/02(水) 18:40:21.61
>>300
ランダムテストとランダムテスト以外の優劣を比較している時点で
ランダムテスト厨や「ランダムテスト厨」厨と変わらないよ
優劣は個別のケースについて検討すべきこと

そして>>296はランダムテストの評価法じゃなくて
仕様を満足しているかどうかの一般的評価法
0303デフォルトの名無しさん2012/05/02(水) 18:43:03.11
ランダムテスト以外とランダムテストの決定的な差は
無限を部分的にでも扱えるかどうかという点

ランダムテストはfor all ...の部分的なテストとみなせる

繰り返すがこれが長所であるかは個別のケースによる
0304デフォルトの名無しさん2012/05/02(水) 19:02:11.39
ランダムテストは、人間が思いもつかないようなバグを発見するのに使える

例えば迷路ゲームを作った時、キャラをランダムな位置から、
ランダムな歩数、ランダムに歩かせて、壁にめり込まないか、
何処かにワープしてしまわないかを検証する

もしめり込んだりしたら、そのケースのテストに使ったデータを基に、
プログラムコードを検証していく

もちろんこれで全ての可能性を網羅できるわけではないが、
人間（デバッガ）の手では出来ないほど大量のケースを短時間に自動で行える
また、人間と違って無意識の先入観が無いことが、
人間が思いもつかないようなバグの発見に繋がる場合も多い

ユニットテストはあくまで人間が思いつくケースしかテストできない
その方が良い場合もあるし、ランダムテストの方が向いている場合もあるし、
ユニットテストしてから、軽くランダムテストしてみる場合もある
0305デフォルトの名無しさん2012/05/02(水) 19:13:32.38
>>304
すまん
実際はアマチュアで個人でプログラムしてるだけで、
テストなんてそうしたことないから適当なこと書いたけど
間違ってないよね？

反応が無いとちょっと心配になってくる
0306デフォルトの名無しさん2012/05/02(水) 19:37:05.29
>>304
言いたいことはわかるし
大きく間違ったことは言ってないと思う
しかし>>300の疑問の答えにはなっていないんじゃないかな
0307デフォルトの名無しさん2012/05/02(水) 19:47:04.38
>>296
例外もテストの結果だ
いろいろおかしいぞ
0308デフォルトの名無しさん2012/05/02(水) 19:49:35.68
>>296は>>295に対するレスってことくらい読み取れよ
いろいろおかしいならおかしい点を建設的に指摘しろよ
0309デフォルトの名無しさん2012/05/02(水) 19:56:18.77
>>308

>>296
> 戻り値を期待結果と比較するのだけがテストじゃないよ

例外の発生有無もも期待結果なの。
あたかも、何か他の手法があるかのように前ふりして、
結局中身がないので読むだけ無駄な点で有害ってこと
0310デフォルトの名無しさん2012/05/02(水) 20:22:53.18
>>309
勝手に変な期待して期待外れだったからって文句言われても
しかも>>300で「一般的評価法」とまで述べているのに

それはそうと
例えばNUnitのConstraint Modelは
事前条件・事後条件・不変条件が明確になるから
仕様との対応が分かりやすいけど
NUnitユーザはConstraint Model活用してる？
実のところ自分はあまり使ってないんだが
03113102012/05/02(水) 20:23:49.72
失礼
>>300でなく>>302
03123102012/05/02(水) 20:52:30.08
なんかスレチだな

複雑怪奇でトリッキーなレガシーコードがあるんですが
読んでられないので実装を無視して
仕様からテストを考えたいと思います
NUnitのConstraint Modelのような記述方法は有効ですか？

うーんやっぱスレチだな
0313デフォルトの名無しさん2012/05/02(水) 21:22:42.41
仕様：
正の整数nに対しf(n)はn未満の偶数を1つ返すものとする
n, f(n)の値はunsigned intで表現できる範囲の数とする

実装：
unsigned int f(unsigned int n)
{
return 0;
}

こういう場合にどういうテストを書けばいいか？という感じか
0314デフォルトの名無しさん2012/05/02(水) 21:29:32.89
あ、正の整数じゃなくて自然数nに訂正
0315デフォルトの名無しさん2012/05/02(水) 21:31:16.19
ゼロを含まない自然数の定義もあるから駄目だな
ゼロまたは正の整数n
0316デフォルトの名無しさん2012/05/02(水) 23:19:35.65
で、どこがテストしにくいの？
0317uy2012/05/06(日) 19:53:12.26
じゃあ俺は
テストしにくいコードを作る方法を教えてください
0318デフォルトの名無しさん2012/05/06(日) 19:58:44.18
>>317
お前がコード書けばいいよ
0319デフォルトの名無しさん2012/05/07(月) 11:01:01.23
>>304
ランダムテストの有効性を問うてるわけでは無くて、ユニットテストという文脈でランダムテストが
有効なのかどうかがこのスレの話題。

> 例えば迷路ゲームを作った時、キャラをランダムな位置から、
> ランダムな歩数、ランダムに歩かせて、壁にめり込まないか、
> 何処かにワープしてしまわないかを検証する

具体的にはどういうコードをどう書いたときに、どのメソッド/関数をテストするときにこのランダム
テストが有効なの？

ユニットテストの概念は、
・呼び出すメソッドが正しい場合に、テスト対象のメソッドが意図通りに動くことを確認するもの
・数学的機能法的な考え方、あるいは、三角推量でテスト対象のメソッドが意図通りに動くことを確認するもの
だと思う。

上記引用部分は、やることが多すぎる。
・ある迷路で
・キャラがある位置にいるときに
・次に歩く一歩を決定し
・キャラを動かして
・壁にめり込まないことを確認
・ワープしないことを確認
・以上を連続でランダム回数行う

これは、俺の認識ではもはやユニットテストの範疇を超えてる。
0320デフォルトの名無しさん2012/05/07(月) 12:50:17.58
適当な事を書いたと言ってる奴にそんなツッコミ入れても・・・
0321デフォルトの名無しさん2012/05/07(月) 13:04:12.00
> 仕様：
> 正の整数nに対しf(n)はn未満の偶数を1つ返すものとする
> n, f(n)の値はunsigned intで表現できる範囲の数とする
f(5)の戻り値が何なのかわからんぞ
0322デフォルトの名無しさん2012/05/07(月) 15:08:42.84
>1って特定の順序を踏んだ場合に線が正常に書けずドット欠けするからテストしたいってのが本当に聞きたかった事だろ？
それは解決したの？
0323デフォルトの名無しさん2012/05/07(月) 15:22:53.70
したでしょ
0324デフォルトの名無しさん2012/05/08(火) 00:48:48.37
>>321
f(5)は5未満の偶数を1つ返すんだから0,2,4のいずれかだろ

これは極端な例だが
結果が一意に定まる一般的必然性はないだろ
0325デフォルトの名無しさん2012/05/08(火) 10:38:13.91
うわこいつめんどくせぇ
0326デフォルトの名無しさん2012/05/08(火) 11:12:23.01
>>324
そういう仕様だとしようか。

で、どこがテストしにくいの？
0327デフォルトの名無しさん2012/05/08(火) 23:10:44.24
2や4がどの程度発生するべきかわからんね
return 0
なら仕様をみたすけど、本当にそれでいいの？使い物になるの？っていう
仕様の不透明な感じがイヤな臭いを放ってはいる
0328デフォルトの名無しさん2012/05/09(水) 10:56:21.24
わからないことは、テストできませんね。不可能。

はい、次。
0329デフォルトの名無しさん2012/05/09(水) 13:52:53.87
仕様が不明確だからテストできないというのは、このスレの対象外の話題です。
0330デフォルトの名無しさん2012/05/09(水) 14:56:17.76
仕様が不明確な場合のテスト方法→仕様を明確にする
0331デフォルトの名無しさん2012/05/09(水) 15:11:14.35

仕様が不明瞭だとテストのしようがありません
0332デフォルトの名無しさん2012/05/09(水) 15:26:06.28
assertInArray([0, 2, 4], f(5));
で十分。
0333デフォルトの名無しさん2012/05/09(水) 20:11:12.49
なんか見てると外延的なのが好きみたいね
内包的な記法の方が流行ってんのかと思った

内包的記法は強力すぎてバグの温床というのも
わからないでもないけど
0334デフォルトの名無しさん2012/05/10(木) 10:31:38.45
強力すぎる内包的記法って、具体的にはどういうやつ？
なんで強力すぎるとバグの温床になるの？
0335デフォルトの名無しさん2012/05/10(木) 12:48:15.35
内包でテストとかもはや何のテストしてるかわからんくなるな
0336デフォルトの名無しさん2012/05/10(木) 21:03:39.02
>>313の例なら
内包的(implicit)
assert(isEven(f(5)) && f(5) < 5);　みたいなの

外延的(explicit)
>>332みたいなの

内包的な記述の方がテスト対象に何を期待しているかを
分かりやすく「厳密に」記述できる
が、isEven()みたいに名前から実装が想像できる場合はともかく
複雑になってくると何をやっているか分らなくなる可能性はある
0337デフォルトの名無しさん2012/05/11(金) 02:11:36.53
>>336
良く考えるんだ。
たとえば、引き数で指定したn個の数をすべて掛け合わせた結果を返す関数
f(x1. x2,…,xN)
を、内包でテスト書いてみ？
0338デフォルトの名無しさん2012/05/11(金) 13:48:03.55
>>336
> 分かりやすく「厳密に」記述できる

うーん、
> assert(isEven(f(5)) && f(5) < 5);
より
> assertInArray([0, 2, 4], f(5));
の方がわかり易いし、厳密だと思うんだがなぁ。まぁ「厳密」の定義とかいう話はしたくないんだけど。
0339デフォルトの名無しさん2012/05/11(金) 22:24:04.44
複雑だけど実行速度が速いアルゴリズムと
シンプルだけど遅いアルゴリズムがあったとき、
前者を実装したコードのテストに
後者を使う事はあるよ
0340デフォルトの名無しさん2012/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()はいくらでも作れる
そういう意味での「厳密」
0341デフォルトの名無しさん2012/05/12(土) 00:37:48.53
だからといって内包的なのが良いとか万能というつもりはない
少なくともテストにおいては

形式手法では話が変わる
0342uy2012/05/12(土) 00:44:24.24
>>340
テスト対象のメソッドの中身と同じようなテストコードを書くか、
別のロジックを書き出すことになるか、
になってしまい
何のテストを書いているかわからんくなるのがオチだろう

テストはそろばんの方がいい
0343デフォルトの名無しさん2012/05/12(土) 01:24:11.65
一般には適用できないが>>337の例なら
・引数のいずれかがゼロのとき結果がゼロになる
・1はいくらかけても1
・log(a*b*...)=log(a)+log(b)+...
とか数学的な性質を使った切り口がいいと思うけどね
内包的に書くにしても外延的に書くとしても
暗算するにしてもそろばんを使うにしても
0344デフォルトの名無しさん2012/05/14(月) 11:51:08.93
>>340
ひょっとして、「仕様の記述レベル」の話してる？
だとするなら、テストメソッド名やコメントに入れれば良いんじゃないのと思うけど。

> assertInArray([0, 2, 4], f(5));
> をパスして仕様に反するf()はいくらでも作れる
いくらでも作れたとしても、それは
> assert(isEven(f(5)) && f(5) < 5);
もパスするよね？
0345デフォルトの名無しさん2012/05/14(月) 15:23:08.70
何を主張したいのか良くわからないけど、
・バグの温床
・複雑になってくると何をやっているか分らなくなる
メリットどこにもないじゃんｗ
0346デフォルトの名無しさん2012/05/14(月) 15:41:59.16
>>333
> 内包的な記法の方が流行ってんのかと思った

というのは、良く目にするということ？
何かの言語界隈とか何かのテストツール界隈では、内包的記法が普通なのかな？
0347デフォルトの名無しさん2012/05/14(月) 17:10:21.27
>>344
assert(isEven(f(n)) && f(n) < n);
にすればいいだけ

>>345
ある方法ではできないことがこの方法ではできる
それを必要とするならメリットだろう
必要を感じない人には関係なかろう
0348デフォルトの名無しさん2012/05/14(月) 17:14:39.34
両方かいとけばいいんじゃね
0349デフォルトの名無しさん2012/05/14(月) 17:25:44.71
>>346
BDDがどのくらい流行っているのか知らないが
仕様とテストコードを近づけるという点では
内包的記法が有効というのは自然な発想だと思う

上の方で出てきたNUnitのConstraint Modelのコンセプトも
それに通ずるものがあるように思う

あと流行ってはいないが形式仕様記述では
内包的記法が無いととてもじゃないが使い物にならない
テストの範疇じゃないけど
03503492012/05/14(月) 17:32:07.61
なんか回答としてぼやけてるな

内包的記法を実際によく見かける訳ではないが
近年のBDDやNUnitのConstraint Modelの登場を見るに
内包的な記法が注目されている気がした
（が別にそんなことはなかったぜ！）
0351デフォルトの名無しさん2012/05/14(月) 17:35:20.61
そもそもassertの中であんまり条件分岐して欲しくない
0352デフォルトの名無しさん2012/05/14(月) 17:44:02.57
>>347
本気でわからん。
> assert(isEven(f(n)) && f(n) < n);
これ、nに何か値を入れないと動かないよね。
n = 5;
assert(isEven(f(n)) && f(n) < n);
とでもするの？

>>349
> 内包的記法が有効というのは自然な発想だと思う
ユニットテストでは、数学的機能法的な考え方や、三角推量、よく知られたテストケースに有効な値
（0とか""とかnullとか）が「それぞれ」正しく動くようにテストを書き実装するというのが有効だ、
というほうが、自然な発想だと思うけどなあ。

まあ、人それぞれなんだけど。
0353デフォルトの名無しさん2012/05/14(月) 17:45:37.17
>>350
そもそも、仕様を記述するときに内包的な記法が有効なのはあたりまえで、

「function f()は[0, 2, 4]のどれかを戻す」

なんて仕様だったら、それこそなんだかわからんわ。
0354デフォルトの名無しさん2012/05/14(月) 17:46:52.48
あ、ひょっとして、
for i in 1..10000
n = random_number();
assert(isEven(f(n)) && f(n) < n);
next
とかしたいのかな？
0355デフォルトの名無しさん2012/05/14(月) 18:24:45.96
たとえば「文字列の中間に'-'１文字挟んで返す」ってときに
内包なんとかで書いていくと
テストコードの方がバグもってるってことが起きるんじゃないの
0356デフォルトの名無しさん2012/05/14(月) 18:25:13.18
>>352
> 数学的機能法的な考え方や、～
が「仕様とテストコードを近づけるという点で」どう役立つのかの方が
俺には分からん

もし数学的機能法が数学的帰納法のことなら
内包的な発想そのものだと思うのだが
0357デフォルトの名無しさん2012/05/15(火) 00:47:43.05
内包でかいたら、
その記述にコードと同様のバグが踏襲されたりして
テストにならんだろ
0358デフォルトの名無しさん2012/05/15(火) 03:16:17.42
>>348の言うように古典的なテストと並記すればいいんじゃね
使えるところだけ使うという合理性はないのか
0359デフォルトの名無しさん2012/05/15(火) 10:55:12.91
>>356
> >>352
> > 数学的機能法的な考え方や、～
> が「仕様とテストコードを近づけるという点で」どう役立つのかの方が
> 俺には分からん
仕様とテストコードを近づける手法を説明したわけでは無くて、ユニットテストの手法として
有効なのはこっちじゃないのという手法を書いた。

> もし数学的機能法が数学的帰納法のことなら
> 内包的な発想そのものだと思うのだが
「発想」と「記述」は別物だよ。記述はあくまで外包的。

結論として、内包的記法が有効なのは仕様とテストコードを近づける面で有効、ということでいいかな？
だとしたら、俺はあんま興味ないのでこれにて終了。

そうじゃなくて、「厳密なテスト」ができるというなら話は別。
0360デフォルトの名無しさん2012/05/15(火) 11:04:34.90
そもそもテストと仕様を記述形式によって近づけよう、近づけたい、という動機がわからない。
0361デフォルトの名無しさん2012/05/15(火) 11:50:07.27
お前ら、テストしにくいコードの話しろよ
0362デフォルトの名無しさん2012/05/15(火) 12:39:22.03
このスレの会話がテストしにくいコードそのものだよ
0363デフォルトの名無しさん2012/05/15(火) 13:23:11.82
まぁソフトウェアテスト総合スレ的なのが無いから、テスト全般について語られるのは仕方が無いともいえる。
テストしにくいコードの話題が無いんだったら、テスト全般の話題でもいいと思うがどうかな。
0364デフォルトの名無しさん2012/05/15(火) 22:39:08.01
>>359
仕様とテストコードを近づけることと「厳密なテスト」ができることは
文法や可読性に重点を置くかどうか程度の違いで実質的に同義じゃないの？
0365デフォルトの名無しさん2012/05/15(火) 22:59:37.28
「厳密なテスト」なんてありえないんだからそりゃ欺瞞だよ
実装コード流用してテストコード書く手間を省いてるだけだろ
0366デフォルトの名無しさん2012/05/15(火) 23:04:56.09
本当にテストしにくい場合
同様の経験がある人同士のあるあるネタ以上に話題が発展しない
別にテストしにくくない場合
素直に解決策が提示されるとそれ以上話題が発展しない
解決策が提示されないと煽りや揚げ足取りに走り話題が発展しない

要するに話題が発展しない
0367デフォルトの名無しさん2012/05/15(火) 23:33:37.52
基本的なこと訊きたいんだが

ゲームを作っていて、全てちゃんとユニットテストから作って、
それにパスするようにプログラムしていたら、
仕様から外れているかどうかを見るタイプのデバッガーは不要になる？
0368デフォルトの名無しさん2012/05/16(水) 00:23:32.08
>>367
少しは上の方のレス読んで自分で考えろよ
既に考えてることがあるんなら後出しせずに先に書けよ

デバッガーが必要かどうかは最終的にビジネスの問題で
プログラム云々の話じゃないというのが個人的な感想
0369デフォルトの名無しさん2012/05/16(水) 01:02:37.76
>>367
> 仕様から外れているかどうかを見るタイプのデバッガー

最近はそんな便利なデバッガーがあるのか？
0370デフォルトの名無しさん2012/05/16(水) 07:19:17.66
>>369
普通にやるだろ。

３つの条件を揃えないとこの扉は開かない、という仕様だったら、
本当に揃えないと開かないのか、別の条件でも開いてしまわないか、
揃えても閉じたままにならないか・・・
デバッガーが開発者の想定外の行動を色々してみて調べる。
0371デフォルトの名無しさん2012/05/16(水) 09:20:25.16
ゲーム業界用語を説明なく使っていることに対する皮肉だろ
0372デフォルトの名無しさん2012/05/16(水) 10:57:47.19
テストプレイヤーのことをデバッガーというのはどうもね。
0373デフォルトの名無しさん2012/05/16(水) 11:04:02.89
>>364
なんとなく文章の解釈とか語義定義とかそんな感じになりそうな気がするが、
そういうのは一切やりたくないので念のため。

> >>359
> 仕様とテストコードを近づけることと「厳密なテスト」ができることは
> 文法や可読性に重点を置くかどうか程度の違いで実質的に同義じゃないの？

仕様とテストコードを近づける手段は、多数ある。
人がレビューするのもそうだし、コメントを書くのもそう。
内包的記述をすることによって、それらを越えるかというと、越えないんじゃ無いのというのが俺の意見。
つまり、内包的記述というのは、今まで出た例から考えると、コメントやテストメソッド名、
あるいはテストメソッド無いの事前・事後Assertion等によって表現するなどの方法と同等じゃないのかと思う。
それを越えているというなら、その内容を教えて欲しい。

厳密なテストというのは、まぁちょっと単語の選び方が悪かった。
> assertInArray([0, 2, 4], f(5));
を意味的に越える（とか書くとまた曖昧になるんだが）記述法が内包的記述かとうと、それもそうでは無いというのが俺の意見。
上記と、
> assert(isEven(f(5)) && f(5) < 5);
は意味的に同じ。
例えば、ランダムテストの手法というのは明らかに上記を越えたテストができる。（ただしそれは「厳密なテスト」ではないが）
0374デフォルトの名無しさん2012/05/16(水) 11:14:54.75
言い方を変える。

内包的記述でしか書けない場面に遭遇したら、それは内包的記述で書けば良い。
それは特殊例として、一般的に内包的記述が仕様を明確/厳密に記述できることを越える、
テスト的なメリットがあるかどうかが知りたい。
ランダムテストには、プログラマが想定しなかったバグをあぶり出すこともあるというのがメリット。
0375デフォルトの名無しさん2012/05/16(水) 17:46:16.04
>>367
プログラマが真の仕様を正しく理解している保証はどこにもないから、たとえプログラマ自身が
100%のテストをしていたとしても、第三者の検証は必要。
これはゲームに限った話では無い。
0376デフォルトの名無しさん2012/05/17(木) 01:25:50.55
>>369
>>370
すれ違いっぷりにわろた
0377デフォルトの名無しさん2012/05/23(水) 22:01:32.86
マルチコア対応のコードをテストするイケてる方法を教えて下さい
とりあえずMPI系
0378デフォルトの名無しさん2012/05/23(水) 22:48:36.91
どんなコードだよ
0379デフォルトの名無しさん2012/05/24(木) 03:29:30.31
便乗ですが、マルチスレッドでクリティカルセクションのロックが適切かどうか、って一般的にはどうテストするのでしょうか？
0380デフォルトの名無しさん2012/05/24(木) 03:58:59.83
正規表現ルーチンはどうすれば効率的な
テストができるんだろう
0381デフォルトの名無しさん2012/05/24(木) 14:42:55.67
>>379
適切
の中身を書くんだ
0382デフォルトの名無しさん2012/05/24(木) 21:11:44.22
>>381
クリティカルセクションを設計段階で見落としてたり、
実装段階でうっかりロックしわすれたりしてる場合に、
きちんと検出するテスト方法が知りたいんす
0383デフォルトの名無しさん2012/05/24(木) 22:01:16.73
>>382
前者は無理だな
設計で考慮してないのをテスト出来るわけがない

後者はマルチスレッドで実際に使うコード書いて、状態に矛盾が発生してないかテストすればいい
0384デフォルトの名無しさん2012/05/25(金) 06:26:18.85
>>382
> クリティカルセクションを設計段階で見落としてたり、

後からテストコードを書けばいいと思ってるからこうなる
0385デフォルトの名無しさん2012/05/25(金) 10:57:00.85
>>382
IBM developerWorks
ConTestを使用したマルチスレッド・ユニットのテスト
並列テストが困難な理由とConTestの活用
http://www.ibm.com/developerworks/jp/java/library/j-contest/
0386デフォルトの名無しさん2012/06/22(金) 09:58:10.84
「Rational テスト仮想化／自動化ソリューション」
テスト期間10日が10分に！日本IBMが仮想テスト環境ツール 2012年06月22日 06時00分更新
ttp://ascii.jp/elem/000/000/703/703943/
　6月21日、日本IBMは仮想的なテスト環境を自動構築するソリューション
「Rational テスト仮想化／自動化ソリューション」を発表した。

　Rational テスト仮想化／自動化ソリューションは、テスト対象となるシステムへの入出力を
仮想的かつ自動的に再現する機能を持つ。これにより、テスト対象システムと接続するシステムの
完成を待ったり、稼働を停止する必要がなくなり、テスト環境を実際に構築することなく接続テストを
実施できる。結果として、テスト時間の短縮やテスト環境構築への投資と手間の削減が実現する。
　また、仮想化環境での接続テストが可能になることで、システム開発工程の早い段階で
不具合の修正ができるため、開発の最終段階での大幅な変更や品質問題発覚による開発遅延の
低減が可能となり、顧客へのサービス開始の遅れや追加コストの発生を防ぐとしている。
　たとえば、海外の金融機関では、テストの大部分を自動化できたことで、手作業による
テスト期間を10日から10分に削減したという。また、ある製造企業は、従来6カ月かかっていた
システム構築を2カ月短縮し、4カ月で完成させたとしている。
　IBM Rational テスト仮想化／自動化ソリューションの使用料金は、4000万円（100PVU）から。
0387デフォルトの名無しさん2012/06/22(金) 20:19:57.32
>>386
お買い得なのかベラボーに高いのか全く分らんな

この手のやつの相場っていくらなの？
0388デフォルトの名無しさん2012/06/22(金) 20:32:02.33
>>387
テスト対象となるシステムへの入出力を行なうのにかかってた時給×対象テスト時間×対象テスト人員数 ＞ よんしぇんまんえん

なら確実にお得
同じくらいか低いなら個別検討っすなー
0389デフォルトの名無しさん2012/06/23(土) 05:57:16.24
>>387
いまいちどういうことをしてくれるのかが良くわからん。

雰囲気は Functional Tester (機能テストツール) + Performance Tester (負荷テストツール) に
仮想環境をセットにしたものみたいだけど、これだけだと 4000万 はさすがに高すぎ (規模によるけど)

ただ気になるのは…

・テスト対象となるシステムへの入出力を 仮想的かつ自動的に再現する機能を持つ
・テスト環境を実際に構築することなく接続テストを 実施できる。

とかで、ここがつぼにはまれば安いのかもしれない。

まあ、この値付けから見て「金融系システム」向けなんだろうから、うちみたいな弱小企業にはあまり
関係なさそう。
0390デフォルトの名無しさん2012/09/30(日) 03:56:58.60
副作用はどうやって楽にテストできるか
0391デフォルトの名無しさん2012/10/10(水) 17:36:13.29
あげ
0392デフォルトの名無しさん2012/10/14(日) 00:02:24.03
テキストボックスから文字を入力して、
所定のラベルに、所定の結果が表示されていること。
これを自動化するにゃどうしたらいい。
こんな感じの検査義読み込んで検査してくれるツールとかあればいいんだけど。
IN:
{
　triggers:
　[
　　{ type:"button", value: "申請" }
　],
　values:
　[
　　{ type:"text", name:"text1", value: "MOX梱包燃料" }
　]
}
OUT:
{
　values:
　[
　　{ type: "label", name: "label1", value: "核取決済状態" }
　]
}
0393デフォルトの名無しさん2012/10/14(日) 00:25:38.89
QuickTestProfessional とか TestPartner でスクリプト書けばいいんじゃね？
0394デフォルトの名無しさん2012/10/14(日) 17:01:51.06
テストしにくいコードっていうのは、
グローバル変数を多用しているコード

今時ねーよというかもしれない。
たしかに、グローバル”変数”を使ってるのは少ない。
だけどグローバルな情報を使っているのは多い。

たとえばデータベース。関数を実行すると
データベースの値が何十個も変わってしまうようなもの。
どこからでもアクセスできるという意味から
こういうのもグローバル変数と同等。

こんなのはテストしにくい。
0395デフォルトの名無しさん2012/10/14(日) 17:23:41.08
>>394
そういうのを副作用というんだよ
0396デフォルトの名無しさん2012/10/14(日) 17:25:14.55
>>395
知ってる。

重要なのは、副作用がたくさんあるコードは
テストしにくいって話。
0397デフォルトの名無しさん2012/10/14(日) 17:34:56.87
最初からそう言えば良いのに
0398デフォルトの名無しさん2012/10/14(日) 17:40:50.03
>>397
それだと一般論で終わるだろ。
0399デフォルトの名無しさん2012/12/15(土) 00:31:27.96
ほしゅ
0400デフォルトの名無しさん2013/01/11(金) 00:56:19.02
形式言語スレできたよ！
案の定過疎ってるよ！

【Alloy】形式言語による仕様記述【VDM】
http://toro.2ch.net/test/read.cgi/tech/1357387746/
0401デフォルトの名無しさん2013/01/27(日) 01:03:25.82
未だに社内でグローバル変数バリバリのCソース書く低能がいて困る
0402デフォルトの名無しさん2013/01/27(日) 01:39:37.10
グローバル変数バリバリで書けるんならむしろ頭が良い証拠では？
コミュニケーションスキルが要求される場面で有能かは別だが

テストまで本人が担当するんなら問題なかろう
別にテスト担当がいるならご愁傷様
0403デフォルトの名無しさん2013/02/20(水) 21:01:52.07
CPUの稼働率を返す関数とか、時刻を返す関数とかどうやってテストしたらええの
0404デフォルトの名無しさん2013/02/21(木) 02:46:23.41
稼働率が0～100%に入っているかくらいはチェックできるだろ

現在時刻ならシーケンシャルに複数回呼び出されるようにして
呼び出した順序と返ってきた時刻の対応関係が正しいかチェック
時間を計測する手段があればそれも使う

一般的な方法として
別の実装方法があればそれと比較する
利用しているAPI等をデリゲートとかでカプセル化してテスト時はモックに差し替える
とか色々
0405デフォルトの名無しさん2013/03/09(土) 09:47:36.78
出力形式がXMLのXSLTのテストってどうやってる？

スキーマ用意して変換結果のValidationは当然やるんだけど
ゆるゆるなスキーマだからテストとしては不十分
仕様上表現が一意に定まらないから単純なテキスト比較もできない

結局XPath式使って評価することになって
Schematronや妥当性を評価するためのXSLTが出来上がるんだけど
あれ？その評価用のXSLTバグってね？みたいな……
0406デフォルトの名無しさん2013/03/11(月) 11:42:17.03
>>405
単純なテキスト比較では駄目な理由は？
0407デフォルトの名無しさん2013/03/12(火) 00:52:07.05
<x a="A" b="B" />
も
<x b="B" a="A"></x>
も仕様上有効ってこと
単純なテキスト比較だと実装と処理系に依存してしまう
名前空間接頭辞やxlinkや実体参照も加わると更にカオス
0408デフォルトの名無しさん2013/03/12(火) 01:25:34.10
ちなみにXML正規化という技術（規格）はあるにはあるんだけどね
0409デフォルトの名無しさん2013/03/12(火) 01:28:32.92
diffxmlとかあのへんは？
0410デフォルトの名無しさん2013/03/12(火) 02:16:55.57
diffxmlで差分が取れたとして
合否のロジックを記述する手段が必要なんでは？
0411デフォルトの名無しさん2013/03/12(火) 02:23:33.75
差分が取れたら失敗でそ
0412デフォルトの名無しさん2013/03/12(火) 02:45:59.51
いやいやいや差分の有無で評価できる場合も当然あるけど
一般に使えるわけじゃない

そもそも問題にしているのは
テストの実現可否じゃなくて（そういう意味ではテストは可能）
テストする手段自体が誤りを含みやすく保守性に欠ける点

いわばXSLTの「テストコード」をどうやってテストするとよいか？
あるいはXSLTのテストコードをテストせずにXSLTの妥当性を評価する妙案はあるか？
0413デフォルトの名無しさん2013/03/12(火) 02:54:40.13
テストにはXSLTを使わない
0414デフォルトの名無しさん2013/03/12(火) 11:20:34.89
>>407
> 単純なテキスト比較だと実装と処理系に依存してしまう

実装と処理系に依存した期待値とのテキスト比較でなぜいけないの？
というか、テストのやり方間違ってないか？
0415デフォルトの名無しさん2013/03/12(火) 11:48:29.91
一体なんのテストがしたいのか、良くわからん。
XSLTに食わせるソースの妥当性？
コードでXSLTを出力していて、そのコードの妥当性？
XSLTを使使った変換ロジックを書いていて、そのコードの妥当性？
0416デフォルトの名無しさん2013/03/12(火) 21:49:13.36
>>414
仕様に無い制約は持ち込みたくない趣味
趣味とはいえ非常識だとは思わないんだが具体的にどう間違ってる？
特に今回は身内で閉じたプロジェクトじゃないってのもある

>>415
>XSLTを使使った変換ロジックを書いていて、そのコードの妥当性？
これ

XSLTを使った変換ロジックの妥当性を確認する手段として
「変換結果の妥当性」を評価している
今はその「変換結果の妥当性」を評価するために別のXSLTも使っている
（別にXPath式を使ったロジックが書けるなら他の手段でも良いが）

今の方法はバグを埋め込みやすいし保守性も悪いと感じているので
エレガントな方法やツールがあったら教えてください
0417デフォルトの名無しさん2013/03/13(水) 02:16:22.67
　　　　　　　／/
　　　　　／　 /　　　ﾊﾞｶｯ
　　　　 //⌒)∩＿＿∩
　　　　/.|　.| ノ　　　　　ヽ
　　　 /　|　| 　●　　　● | 　　　　
　　　/ 　|　彡　　( _●_)　ミ 馬鹿には無理
　　 /　　|　ヽ　　|∪|　　/＿
　　/／　│　　　ヽノ　　＼／
　　"￣￣￣￣￣￣￣（..ノ
0418デフォルトの名無しさん2013/03/13(水) 06:04:15.92
>>416
俺ときみで用語の理解に違いがあるのか、何をテストしたいのか今一よくわからない。
俺が理解するXSLTとはスタイルシートのことで、それをテストするというのがよくわからない。
ひょとして、君が作っているのはXalanのような変換ロジックなのか？
それとも、マニュアルで準備したXSLTが妥当な(要件にマッチした)ものかどうかを確認したいのか？
何れにせよ、決められた入力に対する期待結果がわからないというのがよくわからない。
int sum(int a, int b)は、入力の組み合わせが2^32*2^32あるからテストできないというようなことなのだろうか。Cコンパイラを作ったが、入力されるソースは無限にあるので、出力したオブジェクトの妥当性がチェックできないとかそういうことなのか。

xUnitは知ってるのか、同値分析は知ってるのか、C0/C1カバレッジの概念は知ってるのだろうか。

何れにせよ、疑似テストコードか具体的なテスト手順を示して、こうだからテストできない/しづらいというのを明らかにしてくれれば、何かアイデアを出せるかもしれない。
0419デフォルトの名無しさん2013/03/13(水) 06:14:33.56
訂正。
同値分析じゃなくて、同値分割と境界値分析。
あとやろうとしてるのは、ホワイトボックステスト？ブラックボックステスト？
0420デフォルトの名無しさん2013/03/13(水) 11:06:00.28
俺もわからない事が多すぎてもにょる。

テストターゲットは何で、どのような方法で実装していて、今現在どうやってテストしていて、
問題点はどこで、なぜそれが問題なのかを教えて欲しい。

>>407
それが仕様上有効なのはわかるが、それがテストにどのように影響するの？

>>412
「一般」とは？

> テストする手段自体が誤りを含みやすく保守性に欠ける点
誤りが含まれやすいと思うのは何故？
保守性に欠けると思うのは何故？

>>416
「仕様に無い制約」って何？

> 今はその「変換結果の妥当性」を評価するために別のXSLTも使っている
具体的には、どう使ってるの？
0421デフォルトの名無しさん2013/03/13(水) 11:09:19.05
> <x a="A" b="B" />
> も
> <x b="B" a="A"></x>
例えばこれが出力結果だとして、なぜどちらになるかわからないのかが謎。

本当にどちらになるのか分からないとしても、出力結果をparseして、
・well-formedである
・xが存在する
・attribute a = "A"が存在する
・attribute b = "B"が存在する
・それ以外のattributeは存在しない
をassertすればいいんじゃね？と思うのだが。
0422デフォルトの名無しさん2013/03/13(水) 19:04:47.22
>>421
>例えばこれが出力結果だとして、なぜどちらになるかわからないのかが謎。

実装によって変わる可能性があると言うことでしょ。
仕様上はどっちも正しいんだから。

>・well-formedである
>・xが存在する
>・attribute a = "A"が存在する
>・attribute b = "B"が存在する
>・それ以外のattributeは存在しない
>をassertすればいいんじゃね？と思うのだが。

を一般化したいと言うことだろ。
0423デフォルトの名無しさん2013/03/13(水) 20:03:52.98
>>422
だから、どうして実装によって結果が変わるのさ?
乱数でも使ってるのか?
同じ入力なら、同じ結果になり、そして自分が実装したコードをテストしようとしてるんだったら、どっちになるかわかるでしょ。

それと、何で一般化したいの？
ランダムな入力でも与えるの？
仮に何らかの理由で一般化したいとしても、parseしてxml node tree objectにしてしまえば、どうとでもなるんじゃないの?
ならないとしたら、なんでならないのか教えて。
0424デフォルトの名無しさん2013/03/13(水) 20:11:36.50
つか、単体テストとかユニットテストはやってるのか？
Unit Testing FrameworkとかAcceptance testing frameworkとかを調べて、どうやって妥当かどうかを確認してるのか調べた方がいいよ。
基本は、期待値を自分で用意して比較する。それがもっとも簡単確実。
どうしてもそれだとテストできない場合は、別のやり方がある。
今回は、どうしてもそのケースとは思えない。
0425デフォルトの名無しさん2013/03/13(水) 21:05:11.99
テストできないのは、ただ単に網羅的なテストケースをあげる能力が無いってだけだと思うよ
0426デフォルトの名無しさん2013/03/13(水) 23:04:39.35
>>418
>俺が理解するXSLTとはスタイルシートのことで、それをテストするというのがよくわからない。
それは「スクリプトはプログラムじゃないからテストするに値しない」と
同程度にナンセンス
XSLTは関数型言語とみなせる（しかもチューリング完全らしい）
0427デフォルトの名無しさん2013/03/13(水) 23:07:54.93
>xUnitは知ってるのか
このスレに書き込んでるんだから当然知ってる
逆にXSLT用のユニットテストフレームワークが
存在していることを知ってて書いているのか聞きたいくらい
0428デフォルトの名無しさん2013/03/13(水) 23:33:18.40
>>423
>同じ入力なら、同じ結果になり、そして自分が実装したコードをテストしようとしてるんだったら、どっちになるかわかるでしょ。
多くの場合はそうかもしれないけど例外はいくらでもあるでしょ

もっともXSLTに限って言えば関数型言語の性質を持っているので
幸い参照透過性という点では心配は少ない

今回は自分が実装したコードを自分でテストしているけど
身内以外もテストを実行できないといけないので
実装依存は（個人の気分としてはしたくないけど）許容しても処理系依存はしたくない

有名どころの処理系で問題なければよいという整理の仕方もあるかもしれないが
それを決めるのは俺じゃない
0429デフォルトの名無しさん2013/03/13(水) 23:44:50.39
イメージが湧かない人のために「簡単な」例題を挙げるなら

2次元のテーブルがあって行が一つのレコードになっている
XML的にはこんなイメージ
<テーブル>
<レコード><カラム1/><カラム2/><カラム3/></レコード>
<レコード><カラム1/><カラム2/><カラム3/></レコード>
</テーブル>

テーブルはレコードの集合(set)であって列(sequence)ではない
0430デフォルトの名無しさん2013/03/13(水) 23:50:11.90
このテーブルの行と列を入れ替えたような新しいテーブルをXSLTで生成する
XML的にはこんなイメージ
<変換後テーブル>
<カラム1集合><カラム1/><カラム1/></カラム1集合>
<カラム2集合><カラム2/><カラム2/></カラム2集合>
<カラム3集合><カラム3/><カラム3/></カラム3集合>
</変換後テーブル>
この変換後テーブルも集合であって列でない
集合なので重複は許容されないが順序は問わない
0431デフォルトの名無しさん2013/03/14(木) 00:03:50.29
XSLTの妥当性をどんな方法でどんなツールでテストするか？
>>412にも書いたが
テストできるかできないかを聞いているのではない

あと例題にケチつけるのは勝手だがそこを議論する気は無い
外部参照があるとか代替グループがあるとか
ちょっと条件を加えるだけで問題が複雑になることは想像に難くないはず
0432デフォルトの名無しさん2013/03/14(木) 04:22:26.99
>>428
だから、そのいくらでもあるという例外が起こるケースはどんな場合なのか聞いてるのだが。
0433デフォルトの名無しさん2013/03/14(木) 09:10:10.18
>>432
偉そうにしてお前は浮動小数点演算もやったことないのか？
0434デフォルトの名無しさん2013/03/14(木) 13:36:38.47
>>433
浮動小数点演算の比較が難しい件と、今回のこととは関係無いと思うが。
0435デフォルトの名無しさん2013/03/14(木) 14:51:27.09
>>428
処理系って何？
0436デフォルトの名無しさん2013/03/14(木) 15:41:48.11
質問者が一番XMLとXSLTに詳しそうだし、自分の環境も問題も一番把握してるようだから、
これ以上ここで粘っても無理だと思う。
0437デフォルトの名無しさん2013/03/14(木) 23:03:09.98
>>434
同じ入力なら、同じ結果になるって妄信している（かのように思える）>>432に
同じ入力でも同じ結果にならない身近な例を挙げただけだ

仕様の範囲内で浮動小数点数の誤差を許容することと
仕様の範囲内でXMLの表現のゆらぎを許容することは
多少は類似性があるんじゃね？

>>435
この文脈で処理系つったら言語処理系だろ
XSLTの場合MSXMLとかXalanとかSAXSONとか
0438デフォルトの名無しさん2013/03/14(木) 23:18:51.33
あ、失礼、SAXON
0439デフォルトの名無しさん2013/03/14(木) 23:55:38.93
>>437
君は元質問者なの？違うの？
元質問者は、XSLTを使った変換ロジック、つまりxalanなどと同じ立場の変換プロセッサを実装し、それをテストしたいのだと俺は理解したんだが。
そうじゃないとしたら、一体何を実装したんだろうか？

マニュアルで準備したXSLTが、要件にマッチしているかどうかという意味で妥当かどうかをテストしたいとか、XSLTを出力するコードを書いて、それをテストしたいというのなら変換結果がわからないとというのは納得できる
が、どうもそうじゃないらしい。

上の方で一度質問したが、今行っているテストを疑似コードでいいから示してくれれば、疑問は解決するんだが。

仮にテスト対象への入力がXSLTではなく、出力がXSLTだとするなら、今度は期待するXSLTとのテキスト比較ではなぜ駄目なのかという疑問が出てくる。
0440デフォルトの名無しさん2013/03/15(金) 00:08:15.34
>マニュアルで準備したXSLTが、要件にマッチしているかどうかという意味で妥当かどうかをテストしたい
これだろう
0441デフォルトの名無しさん2013/03/15(金) 13:22:03.55
>>440
だとしたら、やっぱこれでしょ。

>>421
>・well-formedである
>・xが存在する
>・attribute a = "A"が存在する
>・attribute b = "B"が存在する
>・それ以外のattributeは存在しない
>をassertすればいいんじゃね？と思うのだが。

これがなんで嫌なのかわからん。
0442デフォルトの名無しさん2013/03/15(金) 20:40:43.52
>>441
その考え方自体を嫌とは言ってない
その一実現手段であるXPath式を使った方法(SchematronやXSLT）は
バグを埋め込みやすいし保守性も悪いと感じていると述べた

何故か？
typoを検出できない（typoってもうまく動作しているようにみえる場合が少なからずある）
大してテスト対象の規模が大きくなくてもアサーションの数が多くなる
しかも似たようなアサーションが並ぶが再利用性は悪い
等々
0443デフォルトの名無しさん2013/03/15(金) 20:42:05.69
だから埋め込んだバグを見つける手段（「テストコード」のテストとか）や
そもそもバグを埋め込みにくくする手段
（LINQ使うと文法チェックと自動補完が使えていいよ！とか)等について
何でも良いから意見を聞きたかった

が、ここを見ている人はそんなこと問題に思ったことないらしい
0444デフォルトの名無しさん2013/03/16(土) 00:46:46.57
なんだ、そんなつまんないことが聞きたかったのか。
0445デフォルトの名無しさん2013/03/16(土) 01:02:03.90
typoがあったらテストが失敗するからいいんじゃないの？
あと、保守性をいやに気にしてるけど、一度書いたテストは保守不要なんじゃないの？
0446デフォルトの名無しさん2013/03/16(土) 10:11:30.30
>>445
>typoがあったらテストが失敗するからいいんじゃないの？
>>442
>typoってもうまく動作しているようにみえる場合が少なからずある
0447デフォルトの名無しさん2013/03/16(土) 10:12:56.07
>一度書いたテストは保守不要なんじゃないの？
基本はそうだが
ロジック階層の抜本的な変更はそうあるもんじゃないけど
データ階層の変更（項目の追加・名前の変更）は十分にあり得るというか実際にある
メインコードであるXSLTの修正も大概ではあるが
テストコードとテストケースの修正はその比ではなくうんざりする
変更の差分だけ追加テストで済めばよいが必ずしもそうじゃない
済んだと思っても追加の変更で首を絞めることにもなりかねんし
0448デフォルトの名無しさん2013/03/16(土) 10:52:56.02
>>446
typoがあってもテストが失敗しないことが多々あるって、そりゃテストコードが糞なだけだ
0449デフォルトの名無しさん2013/03/16(土) 10:55:56.86
>>447
もはやXSLTとか関係ないじゃん
どううまくやるかってのはそれこそケースバイケースで、お前がこれまでに出した
情報ではアドバイスできる奴いないと思うわ
0450デフォルトの名無しさん2013/03/16(土) 11:47:12.90
話がループするなぁ

XMLを出力するXSLTは実装や処理系で出力結果が一意に定まらないから
単純なテキスト比較ができないところが発端になってる

多くのRDBMSやクエリ言語ではそういう問題は少ないし
SQL関係は情報もツールも充実している
XML関係は情報こそ充実しているものの入門や規格解説レベルのものが多くて
実務上のノウハウに関する情報は多くない
0451デフォルトの名無しさん2013/03/16(土) 11:55:54.88
XML関連で重要な働きをするXPath（XQueryを含む）は使う分には便利だが比較的難解
(感覚的には間接参照の概念を理解していてもC++のポインタがハマりやすいのに似ていると思う）

その他XML Schemaの複雑さとかXLinkによる参照とか「テストしにくさ」に繋がる
背景的要因が多々存在する

そういった背景を無視してXSLT関係ないって言えるのか？
表面的な部分だけ一般的問題に帰着させてないか？
0452デフォルトの名無しさん2013/03/16(土) 12:00:43.15
ケースバイケースでも有用な議論はできるだろう
こういうケースならこれでうまくいくって情報は
たとえ直面している問題に適用できなくても価値があるだろう

個別の議論に付き合いたくなければ黙っていればいいだけ
どうせもともと過疎スレなんだし
0453デフォルトの名無しさん2013/03/16(土) 12:05:31.95
そもそも何のスレです？
0454デフォルトの名無しさん2013/03/16(土) 12:18:38.60
>>1を尊重するなら
「テストしにくいコードをテストする方法教えて下さい」
>ここで言うテストっていうのは
>ユニットテストみたいなものね。
なスレ

今の流れがスレチだと思うなら別のネタでも提供すれば？
どうせgdgdな議論になるか過疎るかのどっちかだ
0455デフォルトの名無しさん2013/03/16(土) 12:29:28.85
俺は自分のことは自分だけで説明したいので…
0456デフォルトの名無しさん2013/03/16(土) 13:18:02.95
だからさぁ、具体的に困ってることを言わないと話が進まないんだって。
処理系が違えば出力結果が違うのはもうわかったからさ、なんでテストで
処理系を固定してはいけないのかとか、typoが致命的な場合ってどういう
ときかとか、実装が異なるってどういうことかとか、具体的に言わないと
改善案は出ないよ。

それと今どうやってテストしてるのか何で言わないの？
それがわからないと改善しようにも、何を改善すればいいのかわかんないよ。
0457デフォルトの名無しさん2013/03/16(土) 13:26:54.93
例えばさ、入力するXMLTをパーズして、テストを自動生成するのができるのかとか、
できたとしてその自動生成ロジックを作る工数とマニュアルでテストを書くのと
どっちが大変かとか、結果の自動判定ロジックはどうかとか、テストを書く人の
スキルはどの程度かとか、俺ら全然わかんないし。
0458デフォルトの名無しさん2013/03/16(土) 13:31:35.65
普通は、typoを減らすには、入力データもテストメソッド内でコードで生成して、
同じ文字列リテラルをAssertでも使うとか言う方法があるんだけど、それは
今回使えるかとか、nameとかvalueは1文字にすればtypoとかないよねとか
そのへんどうなのよ。

大量のAssertが嫌とか、じゃぁ目視でテストすればとか嫌み言いたくなるよ。
0459デフォルトの名無しさん2013/03/16(土) 13:36:48.88
そうそう、まあ過疎スレなんでいないとは思うが、これまでに評価したXSLTの
xUnotは何で、それのどこが駄目かを書くとか。

って書いてて思ったんだが、最も目的に近いxUnitを改造すればいいんじゃね？
0460デフォルトの名無しさん2013/03/16(土) 13:40:08.02
typoもあるし変な文章になったけど、具体的に書けばひょっとしたら経験者がいるかも
しれないし、Googleでも検索にヒットするようにならるから、誰かが来るかもよ。
まあ、ないとは思うけど。
0461デフォルトの名無しさん2013/03/16(土) 14:30:14.12
雑談ネタとして挙げたのに面倒な流れになったな

別に秘匿したい訳でもないし話が進むってなら答えるけど

>>456
>なんでテストで処理系を固定してはいけないのか
>>428
>身内以外もテストを実行できないといけない
テストまで含めて成果物
自分がミスしていないかチェックする手段を
非公開で持っておくというのも手ではあるけどやっぱり二度手間だよね
0462デフォルトの名無しさん2013/03/16(土) 14:56:58.81
>>typoが致命的な場合ってどういうときか
致命的かどうかは状況によるが
XPathで
/a/b//c[@x='X']
と書くべきところを
/a/b/c[@x='X']
と書いても
どちらもXPath式としては有効だし結果は同じになるかもしれない
テストケースはできるだけシンプルにするのでなおさら
0463デフォルトの名無しさん2013/03/16(土) 15:06:05.43
>実装が異なるってどういうことかとか
>>429-430の例でいえば
レコードを上からなめるか下からなめるかの少なくとも2つの実装が考えられる
2つのXSLTで出力結果（<カラム*集合>内の要素の順番）は変わるだろう
普通は上からなめるだろうけどそんな制約は仕様にないので
勝手に仮定してテストを書くべきじゃない
全通りのテストを作る方法もあるだろうが組み合わせ爆発が容易に想像できる
0464デフォルトの名無しさん2013/03/16(土) 15:07:29.10
>>461
また話が見えなくなったが、テスト実行環境も含めてリポジトリに登録すればいいんじゃないの。

>>462
XPath使うのやめれば？
0465デフォルトの名無しさん2013/03/16(土) 15:09:34.15
>>463
ますます話が見えないんだけど、XSLTが二つあったら、それぞれに対してテストケースを
設定するのは普通だよ？
0466デフォルトの名無しさん2013/03/16(土) 15:11:53.41
>それと今どうやってテストしてるのか何で言わないの？
>>405の時点で
>結局XPath式使って評価することになって
>Schematronや妥当性を評価するためのXSLTが出来上がるんだけど
って書いているし
>>416でも
>「変換結果の妥当性」を評価するために別のXSLTも使っている
>（別にXPath式を使ったロジックが書けるなら他の手段でも良いが）
って書いてるのはガン無視か？
0467デフォルトの名無しさん2013/03/16(土) 15:12:07.31
あちょっとまて。
XSLTって変換プロセッサのこと？
だったら一つに固定することで解決するよね。
0468デフォルトの名無しさん2013/03/16(土) 15:18:10.56
>>466
うーん、俺に言わせればそれ全然具体的じゃないんだよ。
例えば、テストを書いてるコードの言語とか、Testing Trameworkは使ってるのかとか、
確認に使うXSLTはどう使ってるのかとか。
0469デフォルトの名無しさん2013/03/16(土) 15:18:54.48
今まで述べてきたXSLTはXSL文書のことだよ
変換プロセッサは処理系って書いてるよ

>>464
>テスト実行環境も含めてリポジトリに登録すればいいんじゃないの。
それは一つの手だと思う
ただ処理効率の悪いXMLがわざわざ選ばれているのは
「誰でも使える」って点が評価されているんだと思うけど
その精神には反するかもね

>XPath使うのやめれば？
それも名案だね
C#で開発してればLINQ使いたいんだけどね
0470デフォルトの名無しさん2013/03/16(土) 15:24:00.19
>>462
//が存在するのがNGなら、それをチェックするツールやAssertを先に通すとかじゃ駄目なの？

っていうか、そういう些末な例じゃなくて、本質的な問題をズバリと言うことはできない？
0471デフォルトの名無しさん2013/03/16(土) 15:28:17.63
>>468
>テストを書いてるコードの言語とか
XSLTでテストを書いてるっていってんだろ

テスト対象のXSLTのテストについては
今回はフレームワークは使ってない
・ファイルの更新チェック
・テスト対象のXSLTのXML SchemaでのValidation
・テストケース（XML文書）のテスト対象XSLTによる変換
・テストケースの変換結果のValidation
・テストケースの変換結果の評価用XSLTによる変換
を行うスクリプトを書いて
Webブラウザをコンソール替わりに使ってる
0472デフォルトの名無しさん2013/03/16(土) 15:31:04.56
>>469
俺が何に疑問を持ってるかというと、テスト対象のXSLTはどういう性質のものかってこと。
ある特定の目的のために、10個20個あって、それぞれに50個のテストを書くようなケースなのか、
何百もあって、個別にテストケースを書くようなことはできないのか。

それと、LINQで劇的にテスト工数が削減できるなら、使えばいいのにって思うんだけど。
なぜ駄目なの？
0473デフォルトの名無しさん2013/03/16(土) 15:34:47.54
>>471
その「を行うスクリプト」が何だか知りたいんだけど。
あと、Testing Frameworkを使わない理由は？
0474デフォルトの名無しさん2013/03/16(土) 15:42:03.36
>>470
だからそれをチェックするツールを知ってるんなら教えてくれって話

時間と金があるなら
形式仕様記述言語からテストコード自動生成とか考えるんだけどねぇ

>そういう些末な例じゃなくて、本質的な問題
何か壮大なスペクタクルでプロジェクトX的なカタルシスを期待してるのかどうかしらんが
typoは所詮typoだよ
とはいえテストが事実上無効化されるという点で馬鹿にできない
0475デフォルトの名無しさん2013/03/16(土) 16:04:58.80
>>472
>テスト対象のXSLTはどういう性質のものかってこと。
仕事の内容だから具体的に書く気はないが
XML Schemaにして400KB程度のスキーマを持つ
データベースのインスタンス文書から可視化できる要素を抽出し
SVGみたいなXMLベース形式に変換するものを書いている
そんなXSLTが数十個

インスタンス文書のパターンは無数にありどれだけテストケースを書くかは裁量による
XSLT内部のtemplate要素は十個程度なので
感覚的には1個のXSLT文書に対し数十個くらいテストケース用意すれば十分だろうという認識
実際そんなにはテストケース用意できてないけど
0476デフォルトの名無しさん2013/03/16(土) 16:12:37.93
>>472
>LINQで劇的にテスト工数が削減できるなら、使えばいいのに
駄目じゃないけど劇的というほど効果がある訳でもないからね
個人的にはXQuery書くよりかは若干精神衛生に良いくらい

テストのためだけにVisual Studio要求するのもアレだし
そもそもLINQってどのくらい一般的なのか知らない
少なくとも自分はホビーでしか使ったことない
0477デフォルトの名無しさん2013/03/16(土) 16:35:49.91
>>473
>その「を行うスクリプト」が何だか知りたいんだけど。
何かって言われても>>471に列挙した
「人間がぽちぽち操作してやる」のを自動化しただけ
XSLT使った変換処理はXSLT処理系に投げているだけで
スクリプトはXSLTの中身について関知していない

>Testing Frameworkを使わない理由は？
XSLTのフレームワーク自体そもそも多くないしデファクトスタンダードといえるようなものもない

一応XUnitとjuxyとTennison Testsを触ったことあるけど
XUnitはあまり問題解決にならない（参考 http://reflex.gforge.inria.fr/xunit.html#N14B88）
juxyは可もなく不可もなくってところだけどJava使うならC#使うかな
Tennison Testsは悪くないと思ったけど導入が手間かな

別に積極的に使わない理由がある訳ではなく
上のスクリプトで自動テストとしては十分な機能があるし
Webブラウザだけあればテストできるし使う理由もないかなと
0478デフォルトの名無しさん2013/03/16(土) 16:41:09.57
そういう意味で気に入ったフレームワークや便利な使い方があったら
教えてくれると嬉しい
0479デフォルトの名無しさん2013/03/16(土) 16:56:18.14
>>465
多分誤解している
XSLTは少なくとも2つ考えられるが2つ書くわけじゃない
リファレンス実装相当を一つ示すだけだ
第三者が別の実装をするかもしれないが
それを想定して複数のテストコードを用意するのは現実的じゃない

繰り返すがテストコードも成果物なんだ
間違っているものを間違っていると言えないテストコードは単なる無能だが
正しいものを間違っていると判断するのは仕様を満たしていない明らかな不良品
0480デフォルトの名無しさん2013/03/16(土) 16:59:46.07
じゃあ、間違っているのを正しいと判断するものは？
0481デフォルトの名無しさん2013/03/16(土) 17:08:30.13
>>480
正しいと「明示」するんなら同様に不良品だろう

ただテストは誤りを見つけるもので
誤りがないことを示すものじゃないってのは常識
0482デフォルトの名無しさん2013/03/16(土) 17:44:21.21
常識とか言われると、じゃあリグレッションテストって何ですかとか言いたくなるわけですが。

それはそれとして、俺とはテストに対する考え方とか自動化の方向性があまりに違いすぎて、
アドバイスはできないということがわかったよ。

色々質問して回答に手間かけさせてごめんね。
0483デフォルトの名無しさん2013/03/16(土) 17:53:24.66
リグレッションテストも
変更に伴う誤りを見つけるためのもので
誤りがないことを示すものじゃないだろ

謝るくらいならテストに対する考え方とか
自動化の方向性について意見を述べてくれてもいいんじゃないか
強制する気は毛頭ないが
0484デフォルトの名無しさん2013/03/16(土) 18:50:58.17
>>457とかちょっと自動化に夢見すぎ
テストを自動生成するためには形式的な仕様がないといけないが
実装から仕様を導出することは一般に困難だ
（仕様書読むよりソースコード読んだ方が分かりやすい！
なーんてことはあるかもしれないけどね！）

テストカバレッジを上げたい
（テストカバレッジを上げることでバグの検出率向上が期待できる）なら有効だろうけど
純粋にバグを見つけたいんならあんまり意味ないな
0485デフォルトの名無しさん2013/03/16(土) 20:22:41.25
>>483
いや、リグレッションテストは、変更によって他が壊れていないかを確認するテストで
バグを見つけるものではないよ。ほら、こういう所にテストに対する考え方の
違いがある。

自動化は、テストデータ生成もテスト実行も結果確認もプログラムでやるのが基本。
CIツールでコミットをフックしてテストを実行できて、結果も取得できなきゃ意味ない。
0486デフォルトの名無しさん2013/03/16(土) 20:27:32.06
>>484
別に夢なんか見てないよ。日常。
自動化は、実行と結果確認が対象。
テストそのものを自動生成できるかどうかは、場合によるよ。
コードで簡単にparseできるものがテストターゲットなんだから、何か自動化
できるものがあるんじゃないかって程度だから、一般に無理とか言われても困る。
0487デフォルトの名無しさん2013/03/16(土) 20:36:04.34
例えば、XSLTを読み込んで、お決まりのテストパターンを含むテストクラスを自動生成する
スケルトンジェネレータとか、その程度でも誤りと手間が減るでしょ。
今回のケースで、それが可能かどうかはわからないけど。
0488デフォルトの名無しさん2013/03/16(土) 21:14:30.08
>>485
他が壊れている状態ってのは誤りじゃないの？
正しいの？正しくないけど誤りでない状態があるの？
まぁ誤りじゃないというならそれでもいいけど
>>481の意味するところは
テストは「そういった不都合全般」を見つけるもので
「そういった不都合全般」がないことを示すものじゃないってこと

用語の解釈に差はあってもテストに対する考え方の違いじゃあないだろう
0489デフォルトの名無しさん2013/03/16(土) 21:34:16.19
>>485
>CIツールでコミットをフックしてテストを実行できて、結果も取得できなきゃ意味ない。
できた方がいいだろうけど意味ないは言い過ぎでは？

>>486
parseできることと意味論レベルで解釈することには差があるからなぁ
あんまり意味ないとは言ったが全部が全部駄目とも言ってない
実際>>487はテクニックとしてはアリだ
問題を挙げるとすればそういうスケルトンジェネレータを俺が知らないことだ

既存ツールなら喜んで使うが自作するとなるとやる気しないね
スキーマによるValidationが有効で
お決まりでないテストパターンで合格しながら
お決まりのテストパターンで不合格になる場合ってのがそうあるもんじゃないし
0490デフォルトの名無しさん2013/03/16(土) 21:44:15.64
勿論typoってのが
>スキーマによるValidationが有効で
>お決まりでないテストパターンで合格しながら
>お決まりのテストパターンで不合格になる場合
に該当する場合があるけどね
0491デフォルトの名無しさん2013/03/16(土) 22:01:22.78
テストには、バグを検出するという目的と、正しく動作するという保証を与えるという目的がある。
リグレッションテストは、後者の方。これは言葉の解釈の問題じゃないよ。テストというものを
どう捉えてるかの問題。Acceptance testも明らかに後者。
正しく動作するという保証を与えるという観点が無いから、お決まりのパターンを軽く見てるんじゃない？

あと、スケルトンジェネレータは自分で作るんだよ。
俺ならこういうのを数時間で作っちゃうし、嫌だなんて思わないよ。むしろ、楽しい。
0492デフォルトの名無しさん2013/03/16(土) 22:05:00.69
> 数時間で作っちゃうし

なんか、仕事のペースじゃないな
そんなゆっくりとしてちゃ仕事にならんだろ。
0493デフォルトの名無しさん2013/03/16(土) 22:21:29.74
>>492
数時間でできあがれば、次の1分で50ファイルそれぞれに20個位のテストが生成されて、
次の1分でビルドして、10秒で1000テストケースの実行が終わる感じかな。
遅くてすみません。
0494デフォルトの名無しさん2013/03/16(土) 22:23:29.75
自動生成されたテストケースに
何の意味があるんだろうか？
0495デフォルトの名無しさん2013/03/16(土) 22:24:15.08
>>491
テストには、バグを検出するという目的と、
正しく動作するという保証を与えるという「心意気」で行うものがあるだろう

が目的が何であろうと
テストによって正しく動作するという「保証」は極々稀な場合を除いて得られない
>>479-481の流れはそういう話だ
0496デフォルトの名無しさん2013/03/16(土) 22:32:58.39
>>494
自動生成の限界については今更議論することじゃないだろう

本格的に自動生成を考えているならこっちで
【Alloy】形式言語による仕様記述【VDM】
http://toro.2ch.net/test/read.cgi/tech/1357387746/
0497デフォルトの名無しさん2013/03/16(土) 22:35:23.40
自動生成の話じゃなくて、
テストケースを自動生成することに
何の意味があるのかってことなんですが？

自動生成プログラムに
間違いがあったらどうするんだ？
0498デフォルトの名無しさん2013/03/16(土) 22:38:58.30
>>497
その問題はテストケースを手動生成すれば解決するのかい？
0499デフォルトの名無しさん2013/03/16(土) 22:39:03.74
限界はあるけど、限界があるから何もしないんじゃなくて、限界の範囲内で
出来ることをやればいいんじゃないかな。
0500デフォルトの名無しさん2013/03/16(土) 22:45:49.29
>>498
自動生成されたものは
どれだけあっても
一個だって言ってるんだよ。
0501デフォルトの名無しさん2013/03/16(土) 22:47:11.43
>>497
今回のXSLTの話とはちょっとずれるけど、既知のテストとして有用な値というのがあって、
例えば0とか1とかINT_MAXとか、""とかnullとか存在しないパスとか、￥とか。
それらを与えるテストを自動生成できれば、assertなしでも少なくとも呼び出せて、
例外が発生しないとか、起こるはずの例外が起こるとか、その程度はできるよ。
場合によっては、いくつかのassertionも自動生成できるかも。
0502デフォルトの名無しさん2013/03/16(土) 22:49:53.61
>>501
そういうのはコンパイラの型チェックにやらせたほうがいいよな。
明らかに駄目なケースというのは、
コンピュータであってもわかるはずだ。
ならばテストを書かずにチェックできたほうがいい。
0503デフォルトの名無しさん2013/03/16(土) 22:52:12.55
>>502
int sum(int a, int b)をどうやってコンパイラにチェックさせるの？
0504デフォルトの名無しさん2013/03/16(土) 22:53:18.89
だからそういう静的解析の類は
形式言語スレの方が歓迎されるよ（たぶん）
0505デフォルトの名無しさん2013/03/16(土) 22:54:36.07
>>503
それに対して

> 例えば0とか1とかINT_MAXとか、""とかnullとか存在しないパスとか、￥とか。
> それらを与えるテストを自動生成できれば、assertなしでも少なくとも呼び出せて、

テストを自動生成できるって話だろ？
できねーよｗ
0506デフォルトの名無しさん2013/03/16(土) 22:57:52.15
>>505
出来ないのか。
じゃ、マニュアルでテスト書くしかないね。
0507デフォルトの名無しさん2013/03/16(土) 22:58:17.26
自動生成したテストっていうのは
要するに同じテストを何度もしているに
過ぎないんだよ。
0508デフォルトの名無しさん2013/03/16(土) 23:02:00.45
>>507
そう思うのは勝手だが
そう思わない人を何のデータもなしに否定しないでほしいね
そう思わない人の多くはきっと>>507の考えている欠点を理解してるよ
0509デフォルトの名無しさん2013/03/16(土) 23:03:02.43
>>508
じゃあ先にデータ出せと。

どんなコードに対して、
どんなテストを自動生成してるんだ？
0510デフォルトの名無しさん2013/03/16(土) 23:03:38.24
>>507
0を与える場合とINT_MAXを与える場合とでは、違うテストのような気がしてるんですが、
俺の気のせいでしょうか。
0511デフォルトの名無しさん2013/03/16(土) 23:05:59.56
>>510
それを、いくつものファイルの
いくつもの定義に対して
自動生成しても意味が無いってこと。

まあ、その場合は2つだ。
ファイルがいくつ有ってもね。
0512デフォルトの名無しさん2013/03/16(土) 23:07:17.46
コンパイルの型チェックにできるテストは「aとbに+をすることができるか？」だけ。
「sum関数に0とnanを渡してnanを返すか？」みたいなテストはできない。
だから>>501みたいなテストを型チェックでやらせようとする>>502はアホ。
0513デフォルトの名無しさん2013/03/16(土) 23:14:45.23
>>510
何が2つなんでしょうか。
xUnitを使ったことありますか？そして、それに付属してたりするスケルトンジェネレータは使ったことあります？
入力ファイル数分のテストクラスができて、その中には公開メソッド数分のテストメソッドが作られます。
これ、いくつですか？

自作のスケルトンジェネレータを作るときに、上記に加えてパラメータの型に着目したテストも
自動生成できるわけなので、さらに数は増えます。
0514デフォルトの名無しさん2013/03/16(土) 23:18:34.05
> 入力ファイル数分のテストクラスができて、その中には公開メソッド数分のテストメソッドが作られます。
０じゃねーの？
どうせそのメソッドの中身空だろ？
0515デフォルトの名無しさん2013/03/16(土) 23:20:12.58
>>512
> 「sum関数に0とnanを渡してnanを返すか？」みたいなテストはできない。

そうだね。0とnanを渡してnanを返すかどうかっていうのは
sum関数に限った話で、その他の関数ではそうなるとは限らない。

つまり自動生成できないわけだよ。
0516デフォルトの名無しさん2013/03/16(土) 23:21:13.98
後付けのテストをする必要があって、尚且つ大量のテストを書く必要があって、
更にテスト対象のドメインや技術に詳しければ、自分で好みのスケルトンジェネレータを
作れるよねってことを言ってます。
そして、それらのテストは、ただ実行できるだけでも価値があります。
0517デフォルトの名無しさん2013/03/16(土) 23:24:11.52
>>513
> 自作のスケルトンジェネレータを作るときに、上記に加えてパラメータの型に着目したテストも
> 自動生成できるわけなので、さらに数は増えます。

だからその自動生成したものを数に加えるなとｗ

ここでやるべきテストは、
「こういう型の時、これらの値を入れた時エラーになるか？」というテスト一個（もしくは数個）だけだ。

その型を使っている所全部にテストコード入れても意味が無いって言ってるんだよ。
同じテストを何度もやってるにすぎない。
0518デフォルトの名無しさん2013/03/16(土) 23:26:15.17
>>515
数学関数ならnan受け取ったらnan返すよ、普通
0519デフォルトの名無しさん2013/03/16(土) 23:26:29.75
>>516
本当に大量のテストをやらないといけないのかを考えることだ。

いくら自動化出来るといっても、テストを実行すればそれだけ時間がかかる。
時間がかかるだけならまだマシだが、修正の際にメンテナンスが必要になるなら
修正の時間もかかる。

テストは必要最小限にするものだ。

数だけ多ければいいと思ってるなら
効果的なテストという発想にはたどり着けないな。
0520デフォルトの名無しさん2013/03/16(土) 23:27:25.21
>>515
最近はSMTソルバを使ってテストやテストケースを作るのが流行ってるよ
使える使えないはともかくできるできないでいえばできる例は実在する

>>517
sum(0,0)もdiv(0,0)も型は同じだけど別モノに思えるけど？
まぁ同じ同じじゃないは主観だけどね
0521デフォルトの名無しさん2013/03/16(土) 23:27:48.93
>>518
それなら、「数学関数」というカテゴリを作って、

そのカテゴリに入っているものは、
nanを返すか？というテストだけでいい。
0522デフォルトの名無しさん2013/03/16(土) 23:28:19.21
>>517
あくまでもスケルトンなので、assertが足りないなら追加するし、メソッドが不足しているなら
追加します。
0523デフォルトの名無しさん2013/03/16(土) 23:29:25.40
>>522
それはテスケースを自動生成したとは言わんだろｗ
お前が手動でテストケース書いてるじゃんか。
0524デフォルトの名無しさん2013/03/16(土) 23:31:17.70
>>519
普段、C0カバレッジで言うと、どれくらいの感じでテストしてます？
0525デフォルトの名無しさん2013/03/16(土) 23:32:44.72
>>521
え？そういうドメイン特化したテストケースの話じゃないの？
0526デフォルトの名無しさん2013/03/16(土) 23:34:37.68
>>523
テストケースは自動生成してますよ。
xUnitのスケルトンジェネレータでいえば、各メソッドにつき一つのPositive Test Caseを
生成しているといえます。
0527デフォルトの名無しさん2013/03/16(土) 23:37:49.21
全部をマニュアルテストするとか、全部のテストをマニュアルで書くとかいうのは絶望的だから、
ちょっと楽できるスケルトンジェネレータを作ってみてはいかがですか、くらいのことですよ。

上手くはまれば、かなりの部分を自動生成できて美味しいよって感じです。
0528デフォルトの名無しさん2013/03/16(土) 23:40:24.43
>>526
えと、そのテストケースを通るようにコードを書くのか？
それともそのテストケースをこれから修正するのか？

今からテストケース作るんだよな？ｗ
0529デフォルトの名無しさん2013/03/16(土) 23:42:28.87
ジェネレートしてしまうと
修正が大変になるからやらないほうがいい。

代わりに、テストケースを一個書いて
それらを複数の関数に適用すればいい。
0530デフォルトの名無しさん2013/03/16(土) 23:46:53.45
>>528
テストケースというのは、テスト項目とほぼ同じ意味で使ってます。
ジェネレートされるのは、テストコードです。
もちろん足りないコードは自分で追加します。
自分が作るスケルトンジェネレータは、テスト対象のことがよくわかってるので、
メソッド呼び出しコードも作れたり、assertも作れたり、例外を期待するコードも
作れたりするでしょう。
0531デフォルトの名無しさん2013/03/16(土) 23:49:02.34
>>530
ジェネレータ無しで
普通に作ればいいのでは？

同じテストは書くだけ無駄なんだからさ。
0532デフォルトの名無しさん2013/03/16(土) 23:49:30.41
>>528
ここで言うテストケースはテスト（テストフィクスチャ）に食わせる入力のことじゃないの？
テストフィクスチャと勘違いしてないか？
0533デフォルトの名無しさん2013/03/16(土) 23:53:02.77
テストケースの話だって言ってるだろ？

もしかして、この馬鹿は
テストフィクスチャ（テストデータのようなもの）を
テストケースと言ってんのか？
0534デフォルトの名無しさん2013/03/16(土) 23:53:23.09
>>529
その方がいい場合もありますね。そして多くのxUnitでは、テストケースを配列で表現して、
同じテストメソッドをその配列数分呼び出す機能があったりします。
そういうのが良い場合は、そういうスケルトンをジェネレートすればいいですね。

他方で、１テストメソッドにつき１assertion派という人たちも存在してます。
0535デフォルトの名無しさん2013/03/16(土) 23:54:28.08
>>534
お前が言ってるのは、テストケースじゃなくて
テストフィクスチャだ。
あほめ。
0536デフォルトの名無しさん2013/03/16(土) 23:56:57.65
もしかして「スケルトン」の意味わかってないんじゃないのか？

スケルトンの意味は骨組み。
中身（テストケース）が無いものだよ。
0537デフォルトの名無しさん2013/03/16(土) 23:57:18.19
>>531
ジェネレータがあった方が楽な場合の話です。
後付けで大量のテストを書くはめになったときとか。
0538デフォルトの名無しさん2013/03/16(土) 23:59:03.54
ユニットテストはじめたばかりなんでしょ？
xUnitの実行結果に書いてある
実行テストケースの数値を無意味に増やすことに
命かけてるんでしょ。
0539デフォルトの名無しさん2013/03/17(日) 00:01:44.99
>>537
もしかして大量のテストが偉いと思ってる？

addという関数があって、1+1、1+2、1+3、1+4・・・
という無限にある計算にたいして
たくさんテストすることが偉いと思ってる？

意味が無いテストはやらないほうがいい。
テストの中身を重視しろ。

そうすれば重複して無駄なテストを減らせる。

もし、コードの行数が多ければ多いほどいいと思ってる会社みたいに、
テストケースの数も多ければ多いほどいいと思ってる会社に
勤めてるならご愁傷様ｗ
0540デフォルトの名無しさん2013/03/17(日) 00:01:55.58
で>>520は正真正銘のテストケース自動生成だと思うけどどうなの？
0541デフォルトの名無しさん2013/03/17(日) 00:02:08.74
>>535
いいえ、テストケースです。
テストケースとは、例えばsum()で言えば、
・どちらの引数も0の場合
・どちらもINT_MAXの場合
それぞれが別のテストケースです。
0542デフォルトの名無しさん2013/03/17(日) 00:03:18.76
>>541
そのテストケースは自動生成されたものじゃないだろ？
出来るわけがないんだよ。

どちらの引数も0の場合の挙動は
sumとdivで違うんだから。
0543デフォルトの名無しさん2013/03/17(日) 00:07:11.81
>>539
100個のクラスがあって、それぞれ10個のメソッドがあり、それぞれにpositive/negativeなテストを
ひとつずつやると、それだけで2000テストケースになります。

全てマニュアルで書くのはつらいし、抜けがあったり間違いがあったりします。
そこをスケルトンジェネレータで楽しましょうという話なんです。

ところで、普段はC0カバレッジはどんな感じでやってます？
0544デフォルトの名無しさん2013/03/17(日) 00:08:36.05
>>542
ケースは自動生成してます。
コードは完全じゃありません。
スケルトンなので。
0545デフォルトの名無しさん2013/03/17(日) 00:08:39.49
100個のクラスがあって、それぞれ10個のメソッドがあり、それぞれにpositive/negativeなテストを
ひとつずつやると、それだけで2000テストケースになります。

それぞれのメソッドは全て機能が違いますので、
何がpositiveになって、何がnegativeになるかはわかりません。

だから自動生成できないのです。
0546デフォルトの名無しさん2013/03/17(日) 00:10:00.56
>>544
スケルトンは、テストケースじゃないぞｗ
0547デフォルトの名無しさん2013/03/17(日) 00:12:24.72
なんか、テストの幻影に騙されてる人みたいだな。
数値ばっかり気にして、その意味まで考えられていない。
0548デフォルトの名無しさん2013/03/17(日) 00:13:56.22
テストケースは自動生成し、それを実行するスケルトンコードを吐き出すのが
スケルトンジェネレータです。
0549デフォルトの名無しさん2013/03/17(日) 00:14:31.35
テストに漏れがあるかどうかは
カバレッジ測定でわかるからどうでもいい。

関数の仕様を考えず、ただ実行したという事実だけを
調べる形だけのテストはいらない。
0550デフォルトの名無しさん2013/03/17(日) 00:15:17.68
>>547
普段C0カバレッジはどんな感じでやってますか？
0551デフォルトの名無しさん2013/03/17(日) 00:15:31.74
テストケースのスケルトンは
テストケースではありません。
ただの関数定義です。

テストとしての意味があってこそ
テストケースと呼べるのです。
0552デフォルトの名無しさん2013/03/17(日) 00:17:39.03
>>549
カバレッジでわかるのは、C0カバレッジでいえば命令網羅率でしかなく、ケースのカバー率はわかりませんね。
0553デフォルトの名無しさん2013/03/17(日) 00:20:16.23
>>551
テスト設計時にテストケース抽出なんて言いますが、あれはいったい何なのでしょうね。
テストコードなんか存在してないのに。

ところで、普段C0カバレッジはどんな感じでやってます？
0554デフォルトの名無しさん2013/03/17(日) 00:20:25.67
だから>>546が期待しているような自動生成はまだ未完成なの
>>546が無駄だとか悪だと思おうが未完成なりに使い道はあるの
しかも研究開発は継続的になされているし
一部のツールには既にスケルトンジェネレータ以上のものが実装されているの
まだ何か言いたいことはある？
0555デフォルトの名無しさん2013/03/17(日) 00:21:27.54
テストなんてやったこと無いので
実のところ分かりません
javac Hoge.java でエラーが出なかったらOKの世界ですから～
0556デフォルトの名無しさん2013/03/17(日) 00:22:34.16
>>554
テストケースの自動生成はできません。
テストケースのスケルトン（骨組み）は
テストケースではありません。
0557デフォルトの名無しさん2013/03/17(日) 00:25:47.61
>>553
> テスト設計時にテストケース抽出なんて言いますが、あれはいったい何なのでしょうね。

最初っからテストコード書けばいいのに、
コードかけないから
エクセルで書く行為じゃねーの？
0558デフォルトの名無しさん2013/03/17(日) 00:26:02.14
>>556
スケルトンがテストケースだろうがテストケースじゃなかろうが
テストケースの自動生成の実例はあるっつってんだろーが
都合の悪いものは見えませんってか？
0559デフォルトの名無しさん2013/03/17(日) 00:28:37.28
もしかしてコーダーじゃねーの？

> 後付けで大量のテストを書くはめになったときとか。
こんなこと言ってるのが気になったんだよ。

テストってのはコード書きながら書くもの。
あの言い方だと、テストは誰かが用意して（エクセルとかに書いて？）
それを見ながらコードを書くのが面倒だって言っているように聞こえる。

だから（エクセルからの）ジェレネータとかいう話になるんだろ。
0560デフォルトの名無しさん2013/03/17(日) 00:29:10.56
>>558
じゃあ、その都合がわるいものを
見せて下さい。

あるんでしょう？
0561デフォルトの名無しさん2013/03/17(日) 00:31:35.96
スケルトンの自動生成の実例を見せられたって意味ないよｗ
0562デフォルトの名無しさん2013/03/17(日) 00:34:44.04
>>559
私も普段はコードとテストは同時に書きますよ。
後付け大量の話は、XSLTの人の場合ですね。
後は、ライブラリやCOMなんかの第三者検証の場合とかですね。
0563デフォルトの名無しさん2013/03/17(日) 00:37:13.77
> 後は、ライブラリやCOMなんかの第三者検証の場合とかですね。

ん？ もしかしてテストコードのレビューをやらないで
自分で一からテストコードを別実装してんの？
0564デフォルトの名無しさん2013/03/17(日) 00:39:14.70
いや、それこそ自動生成できないだろ
ソースコード無いんだから。
0565デフォルトの名無しさん2013/03/17(日) 00:44:46.13
>>563
そのテストコードってひょっとして開発者が書いたものですか？
だとしたら、それはないですね。第三者検証をするんのであって、
開発者テストのレビューをするのではありません。
0566デフォルトの名無しさん2013/03/17(日) 00:45:24.52
>>560
めんどくせー奴だなぁ
実際にオープンソースで動くものの例としてはこれとか
http://llvm.org/pubs/2008-12-OSDI-KLEE.pdf
この論文自体には自動生成の具体例がないけど関連文献でも読んでみれば？
0567デフォルトの名無しさん2013/03/17(日) 00:45:55.04
自動生成の具体例がないけど
自動生成の具体例がないけど
自動生成の具体例がないけど
自動生成の具体例がないけど
0568デフォルトの名無しさん2013/03/17(日) 00:46:37.58
机上の空論じゃない、実際に動くテストコード生成ツール
https://code.google.com/p/crest/

ソースコードをOCamlで書かれたツールで解析して、
分岐構造を抽出し、求めた分岐条件をSATソルバーにかけて
全分岐を網羅するための入力値を得て、テストコード生成までやる
0569デフォルトの名無しさん2013/03/17(日) 00:51:31.00
>>562
お前の話の本筋を否定する気はないが
XSLTの人はコードとテストを同時かテストを先に書くぞ？
by XSLTの人
0570デフォルトの名無しさん2013/03/17(日) 00:53:15.33
>>569
勘違いしてました。申し訳ない。
0571デフォルトの名無しさん2013/03/17(日) 00:55:42.11
カバレッジを上げることが目的になってしまってるな。哀れ。
0572デフォルトの名無しさん2013/03/17(日) 01:04:04.29
ここらで一旦アイちゃんの出番だな。
0573デフォルトの名無しさん2013/03/17(日) 01:08:31.28
だれでも一度は アイ!アイ!
それが最高の アイ!アイ!
だれでも夢見る アイ!アイ!
それはナイショ DE アイ!アイ!
ア・ア・ア・アイ! ア・ア・ア・アイ!
Fu!Fu! Fu!Fu! ア・ア・ア・アイ!
ア・ア・ア・アイ! Fu!Fu!
0574デフォルトの名無しさん2013/03/17(日) 01:13:54.62
バグが10個あるなら10個のテストで検出するのが理想だねなんて
以前西先生がどこかでおっしゃってましたが、普通はそんなこと
できないわけで、じゃあどうするかというとある程度カバレッジを
上げるのが、最もコストの低いやり方だと思います。

第三者検証ではブラックボックステストを行うので、コードのカバレッジは
分からないので、漏れのないテストケースを考える必要があります。
0575デフォルトの名無しさん2013/03/17(日) 01:32:51.99
> 西先生
だれ？


あー、いい。いい。
お偉いさん（笑）だろうから。

先生だもんねｗ
0576デフォルトの名無しさん2013/03/17(日) 01:51:17.64
プログラミングスレ
http://hayabusa.2ch.net/test/read.cgi/news4vip/1363452391/
0577デフォルトの名無しさん2013/03/18(月) 17:25:44.20
>>575
西康晴
0578デフォルトの名無しさん2013/03/18(月) 22:27:44.54
>>577
了解

約 6,300 件 （0.32 秒）
0579デフォルトの名無しさん2013/05/25(土) 20:55:29.72
テストを分かってないやつばかりだな
0580デフォルトの名無しさん2013/05/26(日) 00:28:18.53
わかってる人が今から説明してくれるそーです
0581デフォルトの名無しさん2013/05/26(日) 00:36:43.93
わーい
0582デフォルトの名無しさん2013/05/26(日) 13:24:47.80
テストを分かってるかテストする方法を教えて下さい

ここで言う後者のテストっていうのは
形式的に表現できるやつね。

2chで煽って優越感に浸るやつじゃありません。
0583デフォルトの名無しさん2013/05/26(日) 13:27:26.89
テストを分かってるかテストする方法をテストするところから始め給へ
0584デフォルトの名無しさん2013/05/26(日) 16:27:09.65
if テストを分かっている
return 分かっている;
else
return 分かってない;
0585デフォルトの名無しさん2013/05/26(日) 19:17:12.04
return テストを分かっている ? 分かっている : 分かっていない;
0586デフォルトの名無しさん2013/05/27(月) 11:01:08.60
if ! 何故バグをつぶすべきかを分かっている
return 分かっていない;
if ! どうやってバグを発見するかを分かっている
return 分かっていない;
if ! バグの潜みやすい設計・構造を分かっている
return 分かっていない;
if ! どうやってバグ発生が収束したことを知るかが分かっている
return 分かっていない;
else
return 分かっている;
0587デフォルトの名無しさん2013/08/14(水) NY:AN:NY.AN
test
0588デフォルトの名無しさん2013/09/08(日) 11:00:39.35
てす
0589デフォルトの名無しさん2013/10/07(月) 07:32:42.65
GUIのテスト何使ってる？
0590デフォルトの名無しさん2013/10/07(月) 20:44:59.67
GUIつってもWebとローカルじゃ違うと思うけど
0591デフォルトの名無しさん2013/10/07(月) 22:28:06.96
>>589
人間

実際の状態遷移の部分であれば自動化
大元の遷移図みたいのはツールと人間
品位系は人間

てのはどう?
0592デフォルトの名無しさん2013/10/08(火) 19:55:16.07
>>590
すまん
今はローカルのアプリのテストしようとしてる

>>591
状態遷移とかのある程度決まってるのはやりやすそう
品位系っていうのは品質ってこと？
確かにこれは人間じゃないとキツそうな気がする



まだツール選んでる状態なんだけど，操作するだけじゃなくて
ある程度，実行とか結果の確認とかまでカバーしてくれるようなフレームワークないかな
JUnitのGUI版みたなやつ
ってかGUIのテストって情報少ないな
0593デフォルトの名無しさん2013/10/08(火) 23:16:13.86
GUIて操作性やデザイン的な部分の設計がクローズアップされやすいですね

GUIは、後から人に優しくしようと修正すればするほどコードが汚くなる

なので、後付けで修正して行くより、はじめから人に優しいGUIの設計しましょうよー

となる感じかな
でも、人間相手の部分はどうしても泥臭いところが出てきちゃう
0594デフォルトの名無しさん2013/10/09(水) 01:29:02.74
ビジョンというかガイドラインというか、方針か。
それを定めて一貫して作れば幾分緩和される。
思い付きで積み上げると、いつかどこかで破綻する。
0595デフォルトの名無しさん2013/10/09(水) 10:18:10.84
>>593
バカはどこまでもバカなんで万人に合わせるのは無理
万人にあわせたGUIはソースも設計もgdgdになる
0596デフォルトの名無しさん2013/10/09(水) 18:31:22.88
1画面にすべての情報が出ている方がいい人 / タブや階層で機能ごとに別れているほうがいい人
マウスだけで操作したい人 / 出来ればキーで操作したい人

性格の違うものを混在させるとgdgdになるので、大切なのはデザイナ/設計者の「整理整頓能力」
0597デフォルトの名無しさん2013/10/09(水) 19:10:32.29
>1画面にすべての情報が出ている方がいい人 / タブや階層で機能ごとに別れているほうがいい人

Windows8/8.1のスタートですねわかります
0598デフォルトの名無しさん2013/10/09(水) 19:29:49.13
デスクトップがアプリやファイルのアイコンで一杯一杯の人
0599デフォルトの名無しさん2014/01/23(木) 08:53:20.43
>>575
こういう考えがクソ品質コードを生み出すんだろうなあ
0600デフォルトの名無しさん2014/01/25(土) 06:16:10.10
つーか、テスト屋で西先生知らないとか、不勉強にもほどがあるだろ…
0601デフォルトの名無しさん2014/02/17(月) 21:13:28.58
レジストリの値を取得する関数のテストって
テスト用に目的のレジストリを書き換えてやるのが一般的？
0602デフォルトの名無しさん2014/02/17(月) 23:26:22.52
今時レジストリを直接いじるのもどうかと思うけど

一般的かはともかく無難にやるなら
レジストリを操作するクラスを作って基本的に自動テストはモックで行う
本当のレジストリ操作部分のテストのみ実際のレジストリを書き換える

複数プロセスが同時に同じレジストリキーにアクセスとか
読み書きの遅延がクリティカルだとか
面倒なこと考える必要がなければどうやろうと大差ない
0603デフォルトの名無しさん2014/02/19(水) 13:34:15.05
単体テストレベルならいちいちレジストリにさわらない
ただしセキュリティ権限で台無しにされないように
初回だけは実アクセスのチェックも必要
0604デフォルトの名無しさん2014/02/19(水) 13:38:49.60
そういえば HKLMとHKCUの内容が重なる項目があって意味不に陥ったこともあったな
0605デフォルトの名無しさん2014/02/19(水) 21:38:46.50
>>601
VMwareで仮想環境作っておけば、テストでレジストリ壊しても平気。
0606デフォルトの名無しさん2014/02/19(水) 23:01:40.57
>>605
今時ならvagrantとか使えばそれなりに仮想環境は簡単に戻せるからな。
0607デフォルトの名無しさん2014/02/20(木) 07:58:55.12
>>602
>>603
>>605
ありがと
プログラムはレジストリ値取得部は完全分離
他の部分はモック使ってテスト
レジストリ部は仮想環境でいろいろレジストリ値いじってからテスト
重要なところは本番と同じ環境でテスト
って感じでやってみます
0608デフォルトの名無しさん2014/03/08(土) 16:29:18.17
例外が発生するかのテストってどこまで厳密に評価してる？
別に例外に限った話じゃないが戻り値の評価と機構が違うという点に着目して

たとえばA or Bの条件でそれぞれ例外A、例外Bを発生させるコードで
A and Bが成立する入力を与えるテストを想定した場合

・種類を問わず例外が発生するか評価
・発生する例外が例外Aか例外Bのいずれかであるか評価
・発生する例外が実装に合った例外A（あるいは例外B）か評価
・発生する例外が一意に定まるよう仕様を追記
・そもそもA and Bが成立する条件はテストしない

などなど

ホワイトボックステストが前提なら3番目もアリだけど
対象コードが呼び出すコードの例外まで考えるとテストの保守が大変だなぁとか
0609デフォルトの名無しさん2014/03/09(日) 06:59:38.98
>>608
Aを発生させた後でどうやってBを発生させるかって話？
0610デフォルトの名無しさん2014/03/09(日) 16:12:04.51
例外Aが発生しても例外Bが発生しても仕様上は間違いでない（仕様が曖昧な）場合
どういうテストを書くかって話でしょ
0611デフォルトの名無しさん2014/03/09(日) 17:49:35.68
両方キャッチすればいいだけじゃね？
0612デフォルトの名無しさん2014/03/09(日) 18:03:55.87
それも一つの解だけど
バグの見逃しが増えるよね？

意図とは違う箇所で「たまたま」例外が発生していたってのは
ありがちなバグ
0613デフォルトの名無しさん2014/03/10(月) 10:48:00.59
テストが書きにくい項目で、どうしても気になるとかコストが見合うということなら、ホワイトボックスでカバレッジテストしたらいい。
0614デフォルトの名無しさん2014/03/11(火) 02:25:12.06
ごもっともだけどその判断が難しいんだよね

自動テストケース生成が
誰でも簡単に使えるようになればいいのに
0615デフォルトの名無しさん2014/03/11(火) 10:51:06.97
>>608
> A and Bが成立する入力を与えるテストを想定した場合

大体は
> ・そもそもA and Bが成立する条件はテストしない
だけど、どうしてもテストしたいなら、
> ・発生する例外が実装に合った例外A（あるいは例外B）か評価
かなあ。

try {
　call_some_func(exception_A_or_B_will_be_occurred);
} catch (ExceptionA& e) {
　// test ok
} catch (ExceptionB& e) {
// test ok
} catch (...) {
　test_fail("unexpected exception occurred.");
}
0616デフォルトの名無しさん2014/03/11(火) 18:20:37.00
>>612
だから例外が発生しないケースもテストするんだろ？アホでつか？
0617デフォルトの名無しさん2014/03/11(火) 18:26:06.28
ひょっとして、テスト対象のモジュール以外のモジュールが発生する例外も含めてテストしようとしてるのかな？
基本的に、テスト対象のモジュールで明示的にthrowしている例外だけテストすれば十分だよ。
0618デフォルトの名無しさん2014/03/12(水) 02:08:14.16ID:6wWJMKTk
>>616
それは当然やるとして
たまたま例外が発生してバグを見逃す事例に対しては無力だと思うが

というよりそれをやっても見逃すから「たまたま」って言うんじゃないの
0619デフォルトの名無しさん2014/03/12(水) 06:04:39.83ID:NWWYt1eZ
>>618
たまたまテストを通ることがあるってのは、例外に限らんだろボケ
0620デフォルトの名無しさん2014/03/12(水) 13:44:38.50ID:h/zQBLYG
>>618
> それは当然やるとして
> たまたま例外が発生してバグを見逃す事例に対しては無力だと思うが

具体的には、どういうケースの場合無力なの？
コードで説明して。
0621デフォルトの名無しさん2014/03/13(木) 22:27:55.72ID:GNayCzVK
>>620
コードで説明しないと話にならないとか上から目線で言って
コード例を示せば
自分はそんなミスしないとか
テストじゃないくてコーディング規約で対処するとか
いちゃもん付けてくんだろ？
0622デフォルトの名無しさん2014/03/13(木) 22:41:43.73ID:GNayCzVK
それでもあえて具体例を示すなら

対象のモジュールのNULLチェックの有効性を確認するために
例外が発生するケース（NULL）および
例外が発生しないケース（非NULL値）を与える

しかしNULLチェックが「無かったら」
それが原因でぬるぽが発生しても不思議じゃない

トートロジー的だが結局
例外が発生するケースでは例外が発生するし
例外が発生しないケースでは例外が発生しない

もちろん
例外が発生しないケースで例外が発生すれば
バグの発見に至るのでそれ自体は有効だが
NULLチェックが無いことを見つけるには無力と言っていいだろう
0623デフォルトの名無しさん2014/03/13(木) 22:48:26.42ID:GNayCzVK
NULLチェック漏れに気づかないはずがないと思うかもしれないが
未定義動作をやってしまうと
コンパイラ様が気を利かせてNULLチェックを消してくれたりする

自分の使ってる言語ではそんなこと起きない？
静的解析ツール使う？
それはよかったね！
0624デフォルトの名無しさん2014/03/14(金) 11:55:52.31ID:lgh9wiAe
>>622
> 対象のモジュールのNULLチェックの有効性を確認するために
> 例外が発生するケース（NULL）および
> 例外が発生しないケース（非NULL値）を与える

それってパラメータチェックの話？
だったら、普通はinvalid_aurgument的な例外をthrowするんじゃないの？
0625デフォルトの名無しさん2014/03/14(金) 20:03:31.70ID:WCCw8rC+
>>622
ばか？別に難しくもなんともない。
つーか、一番簡単な類いのテストだろ。
あほらし
0626デフォルトの名無しさん2014/03/15(土) 00:35:00.68ID:gtOzX8mP
>>624
どんな例外投げるかなんて議論してないし
言語や文化で様々なのにこちとら関知しねーよ

普通invalid_aurgument的な例外をthrowするから何なの？

java.lang.NullPointerException以外はぬるぽと認めない
という主張なら否定する気はないが
そういう主張じゃないんだろ？

>>625
どこまで厳密に評価するかの判断が難しいだけであって
そりゃあテスト自体は難しくもなんともないだろう
つか>>622は>>620への回答のつもりなんだが
0627デフォルトの名無しさん2014/03/15(土) 05:32:07.63ID:9w4dPu6Y
>>608で書いてた問題意識と全然関係ないやん
馬鹿丸出し
0628デフォルトの名無しさん2014/03/15(土) 07:12:52.21ID:gtOzX8mP
全然関係ないって
>>612のようなことを一切考慮せずに
>>608のA or Bの条件でそれぞれ例外A、例外Bを発生させるコードの
テストを考えちゃうってこと？

そういう割り切りも有益だが
他人を馬鹿にできるほど褒められるもんでもないと思うが
0629デフォルトの名無しさん2014/03/15(土) 09:26:53.67ID:9w4dPu6Y
だーかーらー、

そんなの、例外であるかどうかと

全く関係ない、

単体テストの

基本中の基本でそ。
0630デフォルトの名無しさん2014/03/17(月) 04:00:33.21ID:CvNwiWhQ
Webのuiのテストにそろそろseleniumとか覚えないとだなーっておもって半年位たってしまった
0631デフォルトの名無しさん2014/03/17(月) 14:37:30.99ID:w+mSad/8
>>626
> どんな例外投げるかなんて議論してないし
俺もそれは議論してないよ。

> 言語や文化で様々なのにこちとら関知しねーよ
言語や文化で様々だから、あなたがどういうケースを想定しているのかを知るために、
どういうコードを想定しているかを最初に聞いたんだけど。

> 普通invalid_aurgument的な例外をthrowするから何なの？
パラメータチェックの話なら、普通は自分で何らかの例外をthrowするはずだから、
テストコードではその例外がthrowされたかどうかをチェックすればいいよねってこと。

> java.lang.NullPointerException以外はぬるぽと認めない
> という主張なら否定する気はないが
> そういう主張じゃないんだろ？
全然そういう主張じゃありません。
0632デフォルトの名無しさん2014/03/17(月) 14:39:34.75ID:w+mSad/8
俺は単純に「たまたま例外が発生してバグを見逃す事例に対しては無力」というケースが
どういうものなのかを知りたいだけなの。

特に何かに関して議論したいとは思ってません。
0633デフォルトの名無しさん2014/03/17(月) 22:15:11.04ID:G262wqxH
>>631
>テストコードではその例外がthrowされたかどうかをチェックすればいいよね
テストコードの良し悪しはともかく
それがバグを見逃す事例って話をしてるのに「いいよね」で片付けちゃダメだろ
何でいいと思うのか説明してもらわないと話が平行線だ
0634デフォルトの名無しさん2014/03/17(月) 22:28:28.69ID:G262wqxH
最近C++書いてないから雰囲気だけど
「たまたま例外が発生してバグを見逃す事例に対しては無力」というケース

void UtilityFunc(const char *p)
{
　if (p == NULL)
　{
　　throw std::invalid_argument("p must be non-NULL");
　}
}

void TargetFunc(const char *a)
{
　if (a == NULL && false) // うっかり
　{
　throw std::invalid_argument("a must be non-NULL");
　}

　// 何かセーフティ・クリティカルな処理

　UtilityFunc(a);
}

NULLではinvalid_argumentが発生
非NULLでは例外が発生しないので
両方やることはバグ(&& false)を見つけることに関しては無力
0635デフォルトの名無しさん2014/03/17(月) 22:31:38.81ID:G262wqxH
先に言っとくが
>>634のコードの問題点の指摘とか解決策の提案とか望んでないからな？
言うのは勝手だが俺に向かって言うなよ？
0636デフォルトの名無しさん2014/03/18(火) 09:53:44.64ID:x5e1HBxb
普通に静的解析で見つかるバグだろ
0637デフォルトの名無しさん2014/03/18(火) 11:24:51.84ID:gETWCJgt
>>634
そういうケースなら、こう。

void testTargetFuncInvalidArgument()
{
　　try {
　　　　TargetFunc(NULL);
　　} catch (std::invalid_argument& e) {
　　　　CPPUNIT_ASSERT_EQUAL(0, strcmp("a must be non-NULL", e.what());
　　}
}

つまり、たしかに特定の場所から例外がthrowされたことを確かめるわけ。
メッセージに「場所」を含めるのも良し。"TargetFunc: a must be non-NULL"みたいに。C++での場合だけど。
0638デフォルトの名無しさん2014/03/18(火) 13:52:27.65ID:gETWCJgt
いや、こうか。

void testTargetFuncInvalidArgument()
{
　　try {
　　　　TargetFunc(NULL);
　　} catch (std::invalid_argument& e) {
　　　　CPPUNIT_ASSERT_EQUAL(0, strcmp("a must be non-NULL", e.what()));
　　　　return;
　　}
　　CPPUNIT_FAIL("no exception");　　// こんなマクロあったっけか？
}
0639デフォルトの名無しさん2014/03/18(火) 14:05:23.28ID:wX7x3AFu
>>637
そういうケースってどういうケース？
それはバグがあることが分かっているから
できる判断じゃないの？
0640デフォルトの名無しさん2014/03/18(火) 14:37:49.28ID:gETWCJgt
>>639
> そういうケースってどういうケース？
> それはバグがあることが分かっているから
> できる判断じゃないの？
いや、そうじゃない。

「そういうケース」というのは、プロジェクト内の至る所で同じ例外クラスがthrowされるケース。
だから、特定の場所で正しくエラー判定がなされ、例外がthrowされたことを確認すればいいわけ。
0641デフォルトの名無しさん2014/03/18(火) 20:38:29.88ID:2087saod
>>634
それ、検出対象が例外なのかどうかと全く関係ないでしょ。
単なる制御構造の条件検出の一般論。
0642 忍法帖【Lv=1,xxxP】(-1+0：5) 【Dtech1395500131639278】 2014/03/22(土) 23:55:31.04ID:o3eAKVXQ
てすと
0643デフォルトの名無しさん2014/04/01(火) 13:53:53.18ID:F/2NOBvh
てすと
0644デフォルトの名無しさん2014/05/06(火) 06:19:15.48ID:eHTf3NEj
テスト
0645デフォルトの名無しさん2014/05/06(火) 11:20:39.39ID:oNAqUNmL
てすと
0646デフォルトの名無しさん2014/05/08(木) 10:56:26.98ID:7mqxxUyE
> なんか誤解してるっぽく見えるからそれをときたいだけなのに原理主義だの教条主義だの
> テスト厨だのって言われるのは心外っすね。。こちらだって別に銀の弾丸だと思ってないし、
> ただ誤った理解を訂正したいだけなのに。。

正しい理解が為されればdisられないという考えがすでに宗教。
だから原理主義言われるんだよ。
0647デフォルトの名無しさん2014/08/20(水) 21:34:50.68ID:i1z9yiRc
てすてす
0648デフォルトの名無しさん2014/08/29(金) 22:38:34.84ID:A/Ep2b4s
クソスレ
0649デフォルトの名無しさん2014/09/14(日) 14:57:49.81ID:9Y2Jt7YQ
クソレス
0650デフォルトの名無しさん2014/09/14(日) 17:56:01.57ID:Bz7JX47u
うんこ
0651デフォルトの名無しさん2014/09/18(木) 01:46:50.83ID:OxIalaPs
ソフトウェアカスタマイズ用のAPI使ったモジュールはテストしにくいよな
テスト用にArquillian的なギミックが用意されてれば別だが
0652デフォルトの名無しさん2014/10/25(土) 22:02:24.00ID:vC010Lko
気合い
0653デフォルトの名無しさん2014/11/06(木) 01:32:06.38ID:Xnznu4wF
外注に投げる
0654デフォルトの名無しさん2014/11/09(日) 12:06:40.41ID:2m8Ee6EB
まんこ
0655デフォルトの名無しさん2014/11/10(月) 22:38:34.29ID:p3rDMgdK
害虫一択だな
0656デフォルトの名無しさん2014/11/23(日) 10:13:44.19ID:tffEMZrq
テステス
0657デフォルトの名無しさん2014/11/30(日) 14:07:45.87ID:Rv000YfS
必要な予算を見積もって外注に投げるでOK
0658デフォルトの名無しさん2014/12/19(金) 23:28:01.93ID:RK4yZsW7
テストのしやすさってどうやってテストするの？
0659デフォルトの名無しさん2014/12/22(月) 15:34:04.02ID:wECaCdvf
テストをしてみればいい
0660デフォルトの名無しさん2015/01/02(金) 09:36:56.19ID:A83rtBgH
てすてす
0661デフォルトの名無しさん2015/01/29(木) 12:30:06.19ID:FsmC2LI9
こういう場合の単体テストってどの単位にどう記述すればいいの？

strutsで言うアクション複数からいくつかある○○業務コントローラーにブン投げて処理
コントローラークラスに業務ロジック全部詰まってる
業務beanに画面表示用の情報も受け取ったパラメーターも全部入ってる
beanを受け取って中身を書き換えるstaticなユーティリティがいくつか
ほとんどのコントローラー内のメソッドは引数に渡したbeanから値を得て、結果のリストなんかをbeanに詰めもしくはメンバ変数に出し入れ
bean内のフラグをみて分岐
beanはセッションに入ってて次のリクエストで前の結果の一部を参照したりする
最終的にJSPで判定しながら出したり出さなかったり

っていう、ため息がでるほど素晴らしい()設計なんだけど。
はぁぁぁぁ、リファクタリングしたい
0662デフォルトの名無しさん2015/01/29(木) 13:02:31.65ID:OdkcJOPr
>>661
struts知らないしbeanがなんだかわからないけど、そのbeanとやらのMockを作ってやればいいんじゃないのと
ちょっとググったら、Struts TestCase for JUnitなるものが存在することがわかった。
これは試した？
あと、他にもxUnitをサポートするツールやライブラリがあるかもよ？
0663デフォルトの名無しさん2015/01/29(木) 13:04:00.91ID:OdkcJOPr
>>661
struts知らないしbeanがなんだかわからないけど、そのbeanとやらのMockを作ってやればいいんじゃないのと
ちょっとググったら、Struts TestCase for JUnitなるものが存在することがわかった。
これは試した？
あと、他にもxUnitをサポートするツールやライブラリがあるかもよ？
0664デフォルトの名無しさん2015/01/29(木) 18:27:27.47ID:5aRBnmo9
beanは大量のメンバにゲッターセッター付いただけの値保持クラス
だからモックにしてもあんまり意味はないかも？
なにも機能は持ってないが、処理から処理へ情報を渡す箱

神オブジェクトが世界を読み書きするためのアカシックレコードとでも言うべきか・・・

xUnit使ってキックできるの分かるけど・・・
どっちかというと、そこでどんな単体テストを設定すれば
こいつの正常動作を保証できるんだろうっていう悩み

いっそリクエストパラメーターと出力されたHTMLの組み合わせだけに着目して内部全部ブラックボックス扱いした方がマシなのかな？
0665デフォルトの名無しさん2015/01/29(木) 18:48:13.65ID:OdkcJOPr
>>664
> xUnit使ってキックできるの分かるけど・・・
> どっちかというと、そこでどんな単体テストを設定すれば
> こいつの正常動作を保証できるんだろうっていう悩み
Strutsを使うと何をどう強制されるのかわからないけど、
beanを受け取ってHTMLを出力するメソッドだけが公開されてるなら、テストは絶望的だね。

Strutsを全然知らずに言うけど、ビジネスロジック層のクラスやメソッドは、FWに左右されないものにして、
Struts無しでテストできるように作れないのかな？

> いっそリクエストパラメーターと出力されたHTMLの組み合わせだけに着目して内部全部ブラックボックス扱いした方がマシなのかな？
これしかないかも。
0666デフォルトの名無しさん2015/02/22(日) 14:22:19.30ID:mDB3/i8f
コントローラーにロジックが詰まってるとはこれ如何に
0667デフォルトの名無しさん2015/02/22(日) 15:04:10.32ID:TfAgRNIZ
えっ？
0668デフォルトの名無しさん2015/05/04(月) 15:35:48.20ID:0fo8dLYV
あっ！！
0669デフォルトの名無しさん2015/07/15(水) 23:07:17.74ID:kjSyKbof
バカがStruts使うとアクションメソッドにビジネスロジックがてんこ盛りなので
0670デフォルトの名無しさん2015/07/16(木) 23:00:01.08ID:QPR01brF
このスレを立てた>>1は何をしたかったのか
0671デフォルトの名無しさん2015/07/20(月) 12:38:37.50ID:VhxPp0/8
まずはモジュール間の依存関係を減らすことだな
例えばデータファイル読み込み処理とデータのDB登録は分離する
0672デフォルトの名無しさん2015/08/05(水) 20:29:18.57ID:0Qsn+5C2
テストしやすいコードを考えるスレではなくて
テストしにくいコードをテストするスレなんだが
0673デフォルトの名無しさん2015/08/05(水) 20:58:58.79ID:2FMwiWRv
テストしやすいようにリファクタリングしましょう
0674デフォルトの名無しさん2015/09/23(水) 15:08:15.35ID:1nbCBLRf
それはテストしにくいコードはテストしやすいように修正しましょうと言っているようなもの
0675デフォルトの名無しさん2015/10/09(金) 15:12:28.43ID:lI8PbTGr
サーバがダウンしたら、待機中のサーバに切り替わるかどうかとかコードを超えたテストはどうやるんですか？？
0676デフォルトの名無しさん2015/10/09(金) 15:18:14.88ID:AB+m/9UF
サーバーのデーモンを止める
0677デフォルトの名無しさん2015/10/10(土) 10:00:13.69ID:395nvZhu
>>675
サーバのダウンをどうやって検出してるか考えればすぐやろ
0678デフォルトの名無しさん2015/10/11(日) 00:23:44.12ID:xhzdVjA8
ソフトウェアに限らず実際に試すわけにいかない機能は
いざというときに往々にして想定どおりには機能しない

そういうのは仕様段階で穴がある事が多いので
コードのテストはほとんど無力
勿論テストしなくていい理由にはならないが
0679デフォルトの名無しさん2015/10/13(火) 10:14:37.20ID:jBFoqp2r
>>678
> ソフトウェアに限らず実際に試すわけにいかない機能は
ソフトウェアだからこそ、実際に試すわけはいかないケースでも、テストできるように実装できると思うよ。
0680デフォルトの名無しさん2015/10/14(水) 08:31:07.88ID:bNV2oMex
ソフトウェアだからこそ実態に合わないテストを容易に量産できるとも言える

プログラミング技術じゃなくエンジニアの心構えの話だがね
0681デフォルトの名無しさん2015/10/21(水) 22:36:38.60ID:0NH3w3Ni
テスト用のサーバーとテスト用の待機サーバーを用意して、テスト用のサーバーをダウンさせたり、ネットワークケーブル引っこ抜いたり…


その後、実機でメンテを長めにとってテスト
0682デフォルトの名無しさん2015/10/22(木) 13:11:49.28ID:522gqyPw
バックアップと復元のテストするときに
バックアップしたあとで本番のデータ消してみるのは怖い
0683デフォルトの名無しさん2015/10/24(土) 07:55:50.61ID:Lznlau7z
スレ違いだ
0684デフォルトの名無しさん2015/11/06(金) 09:06:20.23ID:eT0NjdBF
>>674
残念だがそれが本質。
ブラックボックステストのブラックボックス部分を、
分割とテスト作りを挟みつつ
徐徐に狭めていく他ない。
0685デフォルトの名無しさん2015/11/06(金) 16:55:14.67ID:bXBG+Vn3
それは一般的な意味でのブラックボックスであって
ブラックボックステストのブラックボックスは
必ずしも解体すべきものじゃないと思うが
0686デフォルトの名無しさん2015/11/07(土) 08:48:23.08ID:t6CLGU5E
一般的なブラックテストのことを言ってる訳じゃなくて
ブラックにしてテストしている範囲を段階的に下げてく、(もしくはあげてく)
ってのがプログラムの基本でしょ。

テストがないなら変な可視性を解体してでもテストを書くべきだよ。

本当は小さい部品からテストつくってくのがいいんだろうけれど、レガシーの場合は
細かい部品の仕様がわかりにくいから仕方なく大きな部分のテストから書くしかないってのが
普通だと思う。
0687デフォルトの名無しさん2015/11/07(土) 09:16:54.26ID:3HrlKorf
この会話がかみ合っていない感じ
0688デフォルトの名無しさん2015/11/12(木) 14:55:59.92ID:7f0DrvDX
スクレイピングのテストってどうしてます？
0689デフォルトの名無しさん2015/11/13(金) 14:38:09.92ID:Pru3Xrsp
スクレイピングとだけ言われても
0690デフォルトの名無しさん2015/11/14(土) 12:57:46.88ID:kYx4kaK6
動いてるかどうかなら動かせば判るしな
0691デフォルトの名無しさん2015/11/29(日) 01:06:54.09ID:tNTBXjHt
レイプとな
0692デフォルトの名無しさん2015/12/30(水) 12:38:52.74ID:vE5epnz1
>>690は書いたコードの一部だけ実行して良しとするタイプ
0693デフォルトの名無しさん2016/01/01(金) 15:02:24.72ID:p+JlyTo9
思い込みや決め付けはテストにおいては禁物だな
0694デフォルトの名無しさん2016/01/03(日) 10:55:24.06ID:jgRNkjAt
という決めつけ
0695デフォルトの名無しさん2016/01/03(日) 14:54:33.87ID:S9L4IMX7
以下無限ループ

ここで停止性問題がうんたらかんたら
0696デフォルトの名無しさん2016/01/24(日) 22:18:30.24ID:eLuVQ3YF
実際のサーバーに繋ぐ場合はエラーや応答コードのパターンを網羅することが難しいだろう
それをどうやってテストするかを聞いてると思うんだが
0697デフォルトの名無しさん2016/01/25(月) 11:41:38.76ID:BxpgBTRy
>>696
use mock
0698デフォルトの名無しさん2016/01/29(金) 22:39:52.20ID:sTsCbzbH
ネットワークだとタイムアウト処理がハマリなんだよなぁ

短い時間でテストしてOKだと思ったら
実際の時間でやると最悪ケースでリソース食い潰すとか
そもそもユニットテストで検出する類のバグではないが
0699デフォルトの名無しさん2016/02/08(月) 18:16:59.85ID:hQVN/n6H
いやユニットテストでやれよ。
0700デフォルトの名無しさん2016/02/08(月) 19:21:23.49ID:B1wV/kIt
どうやって？
0701デフォルトの名無しさん2016/02/08(月) 19:52:45.01ID:5cYCGbxv
>>698
タイムアウトを確認するテスト？
0702デフォルトの名無しさん2016/02/09(火) 00:12:01.17ID:Wfs8IlNy
いまだに全部Excelにテスト書いて、手動で動かしてExcelにエビデンス貼り付け…
0703デフォルトの名無しさん2016/02/09(火) 00:19:21.84ID:qKGc1QL2
>>702
手動がなんなのか分からないけど、完全な自動化なんてないから。

自動化するためのテスト、確認をしてたら意味がない。
0704デフォルトの名無しさん2016/02/09(火) 04:21:17.44ID:Wfs8IlNy
>>703
誰が完全な自動化なんていったの？
0705デフォルトの名無しさん2016/02/09(火) 12:19:04.20ID:W/kTUAFF
pexpect
0706デフォルトの名無しさん2016/02/09(火) 15:53:18.36ID:5Crt5HD4
>>702
それsiに派遣されてた時よくやってた
0707デフォルトの名無しさん2016/02/09(火) 17:09:05.75ID:qKGc1QL2
業務システムは品質第一だからな。
証拠を確実にドキュメントとして残す必要がある。
0708デフォルトの名無しさん2016/02/09(火) 17:34:08.30ID:zKyrJnIK
×業務システムは品質第一だから
○偽装型多重派遣システムでは責任の所在が第一だから
0709デフォルトの名無しさん2016/02/09(火) 17:35:35.68ID:kTmgXaKs
誰も見ねえよあんな膨大な量
0710デフォルトの名無しさん2016/02/09(火) 17:55:09.64ID:wyjSQA63
>>707
今やってるプロジェクトのunit testは3000個くらいあるが。
ドキュメント化って1ページ10個で300ページもかけってか。
0711デフォルトの名無しさん2016/02/09(火) 17:58:38.38ID:wyjSQA63
NTTD仕切りの某システム(数千人月)では、Javaで作った部分の単体テストはC1カバレッジ100%必須で
ドキュメント必須みたいは話してたが、あれどうなったんだろうな。
俺は途中で抜けたから、結末は知らんが。
0712デフォルトの名無しさん2016/02/09(火) 19:03:08.90ID:qKGc1QL2
データメインのプログラムだと単体テストをしっかりやらないと大変なことになるからな。

ちゃんと確認すると必然的にExcelのドキュメントができあがる。
0713デフォルトの名無しさん2016/02/09(火) 19:15:21.13ID:zKyrJnIK
>>711
マネージャーの首すげ替えで劇的に改善されると予想
0714デフォルトの名無しさん2016/02/09(火) 19:46:23.41ID:/K/0jua9
テストレポートぐらい自動生成しろよヘタクソ
0715デフォルトの名無しさん2016/02/09(火) 20:06:59.24ID:AjhTI0tJ
コード１りに書かせてあとはテストとドキュメントで余裕
あとマネージャーはクビで
0716デフォルトの名無しさん2016/02/09(火) 20:14:49.97ID:qKGc1QL2
>>714
今度はそれが正しいのかという話になる。
0717デフォルトの名無しさん2016/02/09(火) 20:33:40.23ID:/K/0jua9
テストコードのテストぐらい書くし、
テストコードのテストの分量はシステム全体のテストの分量に比べれば圧倒的に少ない。
0718デフォルトの名無しさん2016/02/09(火) 20:34:18.68ID:/K/0jua9
それがダメだというならコンパイラのテストからはじめて
全エビデンスを貼り付けてみろって話だ。
0719デフォルトの名無しさん2016/02/09(火) 21:43:31.40ID:qKGc1QL2
テストレポートの自動生成があまりよくないと言ってるんだが？
0720デフォルトの名無しさん2016/02/09(火) 22:09:16.63ID:vsEmDrFF
自動テストがどーのこーの言う前に、コンパイラが正しいことを証明しろ。
0721デフォルトの名無しさん2016/02/09(火) 22:58:46.25ID:zKyrJnIK
いやお前らの眼と脳が腐ってないことを証明しろ
0722デフォルトの名無しさん2016/02/10(水) 01:52:23.20ID:l/NE9Don
>>720
コンパイラじゃなくてCPUじゃないのか？

昔のCPUは結構、バグあったぞ。
0723デフォルトの名無しさん2016/02/10(水) 13:56:06.91ID:6Jvpj0vj
>>719
自動生成せずにどうやって作るんだよ？
ひょっとしてマニュアルか？ｗ
0724デフォルトの名無しさん2016/02/10(水) 16:00:14.26ID:lL2Wg2mH
テストしたんじゃなくて、ただ作業しただけ？
0725デフォルトの名無しさん2016/02/10(水) 16:13:40.29ID:DKXnf66E
え？
今時、レポート自動生成もできないような方法でテストしてんの？
今は21世紀ですよ、おじいちゃん？
0726デフォルトの名無しさん2016/02/10(水) 16:15:46.85ID:6Jvpj0vj
>>724
テストという作業をしたのですが
0727デフォルトの名無しさん2016/02/10(水) 16:39:29.26ID:lL2Wg2mH
このスレの話題はテストではなく、テスト作業だから、仕様通りかどうかなんてお構いなしの方々なんでしょうね。
0728デフォルトの名無しさん2016/02/10(水) 16:43:14.76ID:6Jvpj0vj
ということにしたい症候群発病
0729デフォルトの名無しさん2016/02/10(水) 16:52:43.67ID:DKXnf66E
lL2Wg2mH は自分の蛸壺っぷりを自覚したほうがいい。忠告。
0730デフォルトの名無しさん2016/02/10(水) 16:59:59.97ID:6Jvpj0vj
検索したけど、テストそのものに関するスレは今はこの板にはないんだよなぁ
まぁ過疎スレだからここでもいいけどさ
0731デフォルトの名無しさん2016/02/10(水) 17:04:34.13ID:lL2Wg2mH
欧米化だな。欧米人はテストが嫌いなんだよ。

完全にテストするつもりがない。

作る方も使う方もバグがあってもお構いなし。

だからだいたい合ってるテストで十分だと思ってる。

欧米人が作るものがバグだらけの状況を見れば分かるだろ。
0732デフォルトの名無しさん2016/02/10(水) 17:08:15.87ID:jnF2JUJT
>>731
同じジャンル、同じ規模のもので
日本が作っているもののほうが
バグが少ない事例を3つ程度上げてみて
0733デフォルトの名無しさん2016/02/10(水) 17:18:37.03ID:6Jvpj0vj
>>731
欧米人がテストを好きか嫌いかはしらんが、テスト関連の書籍は大抵欧米発だし
雑誌も古くから多くあるし、
http://blog.livedoor.jp/prjmng/archives/52303928.html
求人も多いぞ
http://www.indeed.com/q-Test-Engineer-jobs.html
0734デフォルトの名無しさん2016/02/10(水) 17:20:23.97ID:6Jvpj0vj
日本は、お寒い状況
http://gihyo.jp/magazine/testpress
（廃刊？）
0735デフォルトの名無しさん2016/02/10(水) 17:22:26.18ID:jnF2JUJT
日本のテストは、技術じゃなくて人海戦術なので
海外のテスト技術をみても、それがテストだってわからないんだよ。
0736デフォルトの名無しさん2016/02/10(水) 17:29:02.21ID:6Jvpj0vj
ここ知ってる人は、プログラマ人口の1%未満だろうな
http://aster.or.jp/
0737デフォルトの名無しさん2016/02/10(水) 21:16:08.26ID:Fa7yaYCB
むこうはテスターに結構金払うんじゃね
日本はプログラマに全てやらすイメージ
0738デフォルトの名無しさん2016/02/10(水) 21:27:58.00ID:jnF2JUJT
>>737
日本で言うテスターなんていない。

いるのはテストエンジニアで、テストの開発者へのサポートや技術指導。
テストの自動化の仕組みの構築などを担当している。

だいたいプログラマが作ってるものの仕様を作ってない人間にわかるわけ無いだろ。
0739デフォルトの名無しさん2016/02/10(水) 21:52:13.16ID:ygiYYn1I
>>738
基本的に外国も人海戦術だが、向こうは時間がなくなれば、バグがあってもリリースしてしまうだけ。

テストエンジニアというのは日本でいうとテスターのこと。

テスターは和製英語。
0740デフォルトの名無しさん2016/02/10(水) 22:14:16.04ID:EoVrAAzq
xUnitでCIだーみたいな話と、SIerの人海戦術テストの話は混ぜちゃいかんだろ。
このスレの対象がどっちなのか知らんけど。
0741デフォルトの名無しさん2016/02/10(水) 22:46:46.63ID:eRJ6+i7X
大手行ってもしょーもないバグばっかだよ。
テストなんかろくにしないw
0742デフォルトの名無しさん2016/02/10(水) 22:59:22.07ID:ygiYYn1I
>>740
ツール使ってテストやった気になってバグ増やしてるのが日本。

もともとバグだらけなのが外国。
0743デフォルトの名無しさん2016/02/10(水) 23:06:58.59ID:ygiYYn1I
テストドライバも知らないようなやつが自動化という言葉を知って、それまで完全に手動でやっていたと思ってるんだろ。
0744デフォルトの名無しさん2016/02/10(水) 23:24:30.70ID:ygiYYn1I
>>1
そもそもテストしにくいモジュールを作るのが悪い。

テストしにくいモジュールは設計に問題がある。

例外処理などはテストできないケースもあるが。
0745デフォルトの名無しさん2016/02/10(水) 23:38:51.28ID:ygiYYn1I
他のスレにもたまにいるがデバッグがテストだと思っている人もいるが、デバッグはテストではない。

またコードのテストそのものは単体テストではない。つまり作ったコードからテスト仕様を作ってはいけない。

コードを作ったときのインプットからテスト仕様を起こさないと、コーティング時のただのミスしか検出できない。
0746デフォルトの名無しさん2016/02/11(木) 00:13:32.68ID:f4AmhyQm
テスト観点を事前に決めていないと、テストケースそのものが漏れる。

逆にテストするまでもない机上デバッグで良いものをテストする必要はない。

テスト仕様のない大量のテストコードの作成、自動化はかえってテスト対象の誤りを隠してしまう。
0747デフォルトの名無しさん2016/02/11(木) 00:20:38.08ID:OZhLkZUr
ま～たりそうろんだよ
てすとしようおこせるにゅうりょくとか
どこからわいてくるのよ
0748デフォルトの名無しさん2016/02/11(木) 01:36:06.56ID:/DIzSOPL
>>746
ぶっちゃけ、エクセルに書かれた大量のテストのほうが
大変なんだわｗ
0749デフォルトの名無しさん2016/02/11(木) 05:02:36.63ID:LmS2pw1V
ホワイトボックステストも知らないド初心者がテスト自動化に反対している

という日本のSIerにありがちな構図が見えてきたw
0750デフォルトの名無しさん2016/02/11(木) 09:40:12.82ID:OZhLkZUr
自動化 < 下請けに設計書とコード任せれば単体テストまで自動でやってくれるよ
0751デフォルトの名無しさん2016/02/12(金) 00:01:42.94ID:Ljz6MKRP
よし我が社もテストの自動化だ
0752デフォルトの名無しさん2016/02/12(金) 01:20:18.06ID:7wnoA+aI
Selenium使ってる人いる？
0753デフォルトの名無しさん2016/02/12(金) 01:50:28.30ID:6TBD71bH
Selenium嫌い。

今ユニットテストをしていて、"追加で"Seleniumを導入して
さらに信頼性をあげようというのならいいけど、

今テスト無い。テスト導入大変。Seleniumなら行けるんじゃね？誰かテスターに作らせてみよう。
などという考えでやると絶対失敗する。実行時間は長いしメンテナンスが大変で。
安定させて動かすことに時間をとられるだけ。

Seleniumを使ってバグを見つけたりリグレッションテストをしようと思っては駄目。
正常系を軽く通してみる。程度の扱いにとどめておくべき
0754デフォルトの名無しさん2016/02/12(金) 04:01:42.02ID:hJ+Q2giD
>>753
ツールの得手不得手を把握して効果的に使えよ。
Selenium嫌いな理由になってないｗｗｗ
0755デフォルトの名無しさん2016/02/12(金) 07:19:56.91ID:vVOTgMMN
ツール導入で単体テストをやった気になってるなら本末転倒。

単体テストレベルのテストを影響確認として繰り返すなら有効だが、そもそも仕様が変わってたら、ただ手間が増えるだけ。
0756デフォルトの名無しさん2016/02/12(金) 07:30:05.58ID:vVOTgMMN
最近の初心者は単体テストのやり方が分からないのか、複雑なテスト用プログラムを作るよな。

テスト対象のテスト以前にテストドライバのテストが必要だろw
0757デフォルトの名無しさん2016/02/12(金) 08:17:17.09ID:GB2qNmet
はいはい、おじーちゃんはエクセルにエビデンスのスクショを貼り付けてくださいね。
0758デフォルトの名無しさん2016/02/12(金) 10:52:51.95ID:4LI1BkOW
>>745
> またコードのテストそのものは単体テストではない。つまり作ったコードからテスト仕様を作ってはいけない。
これが
>>719
> テストレポートの自動生成があまりよくないと言ってるんだが？
の理由なのかな。

> コードを作ったときのインプットからテスト仕様を起こさないと、コーティング時のただのミスしか検出できない。
コードを作ったときのインプットからテストコードを書いて、それのテストレポートを自動生成すればいいよ。
0759デフォルトの名無しさん2016/02/12(金) 10:56:33.13ID:4LI1BkOW
>>755
> 単体テストレベルのテストを影響確認として繰り返すなら有効だが、そもそも仕様が変わってたら、ただ手間が増えるだけ。
別にツールを使わなくても、どんなやりかただって仕様が変われば
・古いテストを削除し
・テスト仕様書が存在するなら変更し
・新しいテストを追加・実行し
・リグレッションテストも必要なら実行する
ということが必要。
0760デフォルトの名無しさん2016/02/12(金) 11:34:03.54ID:GB2qNmet
っていうか、今時はCIクラスタサーバでリグレッションテストかけっぱなしだろ？
0761デフォルトの名無しさん2016/02/12(金) 13:09:10.57ID:4LI1BkOW
>>760
>>759の作業項目は、commitする前もしくはbranchにmergeする前に個人が行うことね。
0762デフォルトの名無しさん2016/02/12(金) 20:01:07.51ID:W1VJFYp+
お前らそんなに気にしてると禿げるぞ
テストなんてしなければストレスフリー
0763デフォルトの名無しさん2016/02/13(土) 00:18:04.18ID:u2nzQZui
>>759
問題は、それを行う手間だよ。

・古いテストが多ければ多いほど、削除する手間はかかるし、
・テスト仕様書が多ければ多いほど、テスト仕様書の変更の手間もかかるし、
・新しいテストが多いほど、追加するコストも多くなるし、
・テスト実行に時間がかかるほど、リグレッションテストの時間もかかる。

>>760
> っていうか、今時はCIクラスタサーバでリグレッションテストかけっぱなしだろ？
リファクタリングしかしないならそうだね。
実際には機能追加や変更があるのでリグレッションテスト以外もしている。
そしてリグレッションテストの数時間かかるようじゃまともにCIできない。

ちなみにSelenium使うと本当に数時間かかるテストになるよ。
実行が遅すぎるんで。
0764デフォルトの名無しさん2016/02/13(土) 00:20:34.24ID:u2nzQZui
>>761
>>759の作業項目は、commitする前もしくはbranchにmergeする前に個人が行うことね。

小さいプログラムならいいけど、大きくなってくると
テストに時間がかかってしまう。

個人単位の作業なら数分以内に終わらないと
とても開発してられない。十分超えたらアウトだろう。

自分の作業範囲と関係ありそうなところだけテストして
時間がかかるものに関してはCIサーバーを使うのが現実的だろう。
0765デフォルトの名無しさん2016/02/13(土) 00:21:45.07ID:u2nzQZui
あと、それでもSeleniumは別にしといたほうがいい。
Seleniumだとバグがなくてもテストが失敗することがあるので
完全自動化は難しい。
0766デフォルトの名無しさん2016/02/13(土) 00:26:32.82ID:KwhsYsVP
>>765
誰がSeleniumで完全自動化できるだなんて言ったの？
0767デフォルトの名無しさん2016/02/13(土) 09:11:39.27ID:j6D4qtnG
まあ、完全にできる/できないで極論ににするのって、
新しい技術を却下する口実の典型だよねw
0768デフォルトの名無しさん2016/02/13(土) 09:36:38.34ID:uLwmuMUC
>>765
>Seleniumだとバグがなくてもテストが失敗することがある
それはテストの書き方がおかしい。Jenkinsとの組み合わせも並列実行もできないお前が悪い。
0769デフォルトの名無しさん2016/02/13(土) 09:50:00.13ID:NiOQpRRl
>>768
バッドノウハウの塊だって言ってるの。
期待通りに動かすために消耗するだけだよ。

http://shanon-tech.blogspot.jp/2011/11/selenium.html

> Jenkinsを導入することで、毎日最新のソースコードで、決まった時間に自動で
> テストが実行されるようになっているのですが、次のような課題を抱えて困っていました。。。
>
> (1) ソースコードを何も変更していないときでも、必ずしも毎回テストがパスしない

並列実行なんて、開発者個人のPCではする意味が無いし、
Seleniumはどうしてもしかたがないときだけ使うべき。
0770デフォルトの名無しさん2016/02/13(土) 09:59:08.01ID:KwhsYsVP
>>769
ちょっとリンク先見たけど、Selenium IDEでテストケースつくってwait処理もしてない素人以下じゃねーかｗｗｗ
0771デフォルトの名無しさん2016/02/13(土) 11:03:56.67ID:NiOQpRRl
そのwait処理っていうのが問題で待たなきゃいけないから時間がかかる。
またどれくらい待たなきゃいけないのか？って話もあって
タイムアウトでエラーになる。
でも運が良ければエラーにならない。

時間がかかるSeleniumのテストで途中でエラーになったら
調整してやり直し。この繰り返しのせいで効率が相当落ちるんだよ。

だからSeleniumはどうしてもしかたがないときだけ使うべきって言ってるの。
0772デフォルトの名無しさん2016/02/13(土) 12:26:37.90ID:j6D4qtnG
え？wait処理しないでseleniumのせいにしてるの？
wait処理したら時間かかるといったって、
その分並列にしたら丁度良い負荷で効率良くテストできるじゃないか…
0773デフォルトの名無しさん2016/02/13(土) 12:32:08.86ID:QkwxgYit
>>771
何か勘違い(思い込み)してないか？ちょっとお前のwait処理見てやるから晒してみ。
0774デフォルトの名無しさん2016/02/14(日) 00:28:11.65ID:zhuBaqVP
>>772
いや、一台のマシン（個人の開発用マシン）で
分散とか意味不明だろｗ

テストっていうのはより速くだけじゃなくて
より早く（コード開発したらすぐに）実行できないと駄目なんだよ。

Seleniumを使ってる時点で早くなることはありえないので
本当に最終確認にのみSeleniumを使うようにしなければ
開発コストもテストコストもかかってしまう。
0775デフォルトの名無しさん2016/02/14(日) 00:31:05.82ID:+jgSWz8w
>>774
だからwait処理晒してみなさい
0776デフォルトの名無しさん2016/02/14(日) 01:52:29.34ID:QJKXq47X
こいつ分散しなきゃ並列実行できないと思ってんのか？
だめだこりゃ
0777デフォルトの名無しさん2016/02/15(月) 10:46:40.42ID:KE3D+bSp
>>764
> 時間がかかるものに関してはCIサーバーを使うのが現実的だろう。
CIサーバで自動テストをしないなんて言ってないんだけど。
CIサーバでは、全員の全テストを実行する。

> テストに時間がかかってしまう。
>
> 個人単位の作業なら数分以内に終わらないと
>>759リグレッションテストは、自分が書いたテストの範囲で行えばOK。
影響のありそうなテストクラスを選択してもいいし、面倒なら全部実行してもいい。

最小作業単位をどれくらいに考えるかによるけど、4時間とか8時間単位なら
最後に数分くらいかかってもいいと思う。
0778デフォルトの名無しさん2016/02/15(月) 10:49:54.67ID:KE3D+bSp
>>764
> 個人単位の作業なら数分以内に終わらないと
> とても開発してられない。十分超えたらアウトだろう。
個人がどういうテストを何個くらい作るのかわからないけど、サーバサイドのテストだったら
1000個で30～60秒くらいで終わらせるようなテストを書くのを目指すのがいいと思うよ。

1000個30秒だったら、1日に1,2回実行してもいいかってなる。
0779デフォルトの名無しさん2016/02/15(月) 11:04:50.48ID:H2cwhcEl
Seleniumでテストすると1テスト（数個のチェック）で10秒ぐらいかかるからな。

一般論としてあるテストが前のテスト結果に依存してはならない、
つまりテスト毎にデータを初期化するべきだから
毎回初期化のためのブラウザ操作が走るからね。

単体テストだとデータ用意して流し込めばいいけどSeleniumだとそれができない。
（それともデータ流しこみ用のテスト専用の管理画面でも作る？ｗ）
0780デフォルトの名無しさん2016/02/15(月) 11:07:30.50ID:KE3D+bSp
>>779
最近はもう、webunitとかhttpunit的なものは使われてないの？
requestして結果をparseして内容を確認する系の奴で、ブラウザがからまない奴。
0781デフォルトの名無しさん2016/02/15(月) 12:03:19.00ID:JgRPJB8C
>>779
だーかーらー、晒してみろって。
1テスト10秒とかあまりにもアレすぎて読んでられない。
0782デフォルトの名無しさん2016/02/15(月) 12:18:24.86ID:H2cwhcEl
>>781
こんな感じ。言っとくけど1チェックじゃなくて
数個のチェックを行った1テストな。

https://youtu.be/C094NXdtZr0?t=16
https://youtu.be/RKDAydzKjLQ?t=12

https://www.youtube.com/watch?v=BtUkFAp4UTg
0783デフォルトの名無しさん2016/02/15(月) 12:39:31.55ID:HDUARmmX
>>782
冗談だろ？古臭いデモじゃなくてお前のコード晒せよ。
0784デフォルトの名無しさん2016/02/15(月) 12:51:47.87ID:H2cwhcEl
YouTubeにあるやつで十分だろ。
お前が晒せよｗ
0785デフォルトの名無しさん2016/02/15(月) 13:12:41.19ID:KE3D+bSp
>>782
ちょっとだけ動画見たが、最近ではPhantomJSとかを使うのが主流じゃないのか？
0786デフォルトの名無しさん2016/02/15(月) 13:15:34.24ID:KE3D+bSp
ちょっとググったが、それほど劇的な高速化が見込めるというわけではないのか。
http://dev.classmethod.jp/etc/auto-test-2/

> 実行速度の比較
> FireFoxと実行速度を比較してみました。
> 今回のプログラムをそれぞれ数回実行した平均時間は以下のようになりました。
> FireFox　10.6s
> PhantomJS　7.9s
0787デフォルトの名無しさん2016/02/15(月) 17:00:41.74ID:JgRPJB8C
だってそれ一度グーグル経由してるんだから時間かかるに決まってるだろ…
0788デフォルトの名無しさん2016/02/15(月) 17:03:35.97ID:H2cwhcEl
Googleのサーバーよりも、うちのサーバーのほうが非力だ。
0789デフォルトの名無しさん2016/02/15(月) 17:40:17.92ID:KE3D+bSp
>>787
> だってそれ一度グーグル経由してるんだから時間かかるに決まってるだろ…
PhantomJSインストールして、そこにどれくらい時間がかかるか計測してみた。

require 'selenium-webdriver'

driver = Selenium::WebDriver.for(:remote, :url => 'http://localhost:9134')

puts Time.now.strftime('%H:%M:%S.%L')
driver.navigate.to 'http://google.com'
element = driver.find_element(:name, 'q')
element.send_keys 'PhantomJS'
element.submit
puts Time.now.strftime('%H:%M:%S.%L')
puts driver.title
driver.quit

--
$ time ruby test.rb
17:38:36.178
17:38:36.866
PhantomJS - Google 検索

real 0m0.950s
user 0m0.217s
sys 0m0.034s

グーグル行って検索して結果取得するのは700msくらいだよ。
0790デフォルトの名無しさん2016/02/15(月) 18:00:23.35ID:H2cwhcEl
Seleniumは完全なブラックボックステストになっていて
ユーザーがブラウザを操作しているのと同じことを行ってテストするんだよ。

それがメリットにもなるんだが、それで多くのテストを行うのは非現実的。

例えばAmazonマーケットプレイスの購入のテストを行うことを考えてみようか？

1. マーケットプレイスアカウントの登録
　顧客情報の入力やら、メール経由でのユーザー確認、ショップ情報の登録等
2. 商品の登録
　ショップ管理者としてログイン、商品データの入力等
3. 購入者アカウントの登録
　購入者情報の入力やら、メール経由でのユーザー確認等
4. 商品の購入
　登録した商品をカゴに入れ、住所などの情報も入力、決済処理を行う


これらをやってようやくSeleniumでテストが出来るんだよ。
時間がかかるのは当然だろう？

これがSeleniumを使わないテストならモジュールレベルでテストできるから
データは適当なものをでっち上げてデータベースに登録して
無関係なログイン処理はすっ飛ばして（適当なモックを使う）
本来テストを行いたい、購入部分だけのテストを行うことが出来る。
0791デフォルトの名無しさん2016/02/15(月) 20:09:57.44ID:HDUARmmX
>>790
非現実的なのはお前の頭だろｗｗｗRCしか知らずに批判してる恥ずかしさよ
0792デフォルトの名無しさん2016/02/15(月) 20:13:17.30ID:H2cwhcEl
え？ RC以外も出してるのに、
何でそんな勘違いしてるのｗ
0793デフォルトの名無しさん2016/02/15(月) 20:15:51.68ID:HDUARmmX
>>792
Seleniumがモック使えないような言い方しといてよくまた出てこれたもんだ。
0794デフォルトの名無しさん2016/02/15(月) 20:24:26.52ID:H2cwhcEl
どうもさっきから反論の仕方がなってないよなｗ

何かができるっていうのなら、それをやって見せれば良いのに。
何も出来ないからそうやって、重箱の隅をつつくなことしてごまかしてるんだろうね。
0795デフォルトの名無しさん2016/02/15(月) 20:26:00.11ID:H2cwhcEl
まあいいや、現時点ではSeleniumは遅い。
それを解決する方法はでてない。
とうことで一旦区切りつけるか。
0796デフォルトの名無しさん2016/02/15(月) 20:29:17.85ID:HDUARmmX
>>794
え、モック本当に知らないの？
議論の仕方がなってないｗｗｗそっくりそのままお前に返すわｗｗｗ
0797デフォルトの名無しさん2016/02/15(月) 22:56:20.73ID:8/hvPvbC
緑色は最悪ですぞ
0798デフォルトの名無しさん2016/02/16(火) 02:23:10.06ID:y+ZjOqCo
>>796
なんでモック知ってるか知ってないかという
無関係な話にすり替えてるんだ？

お前が、Seleniumを使って短時間（ミリ秒レベル）で
テストできることを実証すればいいんだよ。

Seleniumは遅いからどうあっても1テストに数秒かかる。
一連のテストだと数十秒、数分になるのは目に見えてる。
0799デフォルトの名無しさん2016/02/16(火) 06:30:31.18ID:Q0jnsQ6e
>>798
誰がSeleniumでミリ秒単位のテストが可能だなんて言ってるの？ツールの得手不得手を把握して効果的に使えとしか言ってねえよｗｗｗ

で、モック使えるの本当に知らないの？
0800デフォルトの名無しさん2016/02/16(火) 14:38:35.00ID:y+ZjOqCo
>>799
モックの話は全く関係ないのでするつもり無いよｗ

でSeleniumは遅いんだろう？
最初からそう言ってるんだが。

遅いから基本的に使わない。
どうしても必要なところだけ使う。
俺と言ってること一緒だよね？

Seleniumは多くテストをやるのに不得意だから
使わないって言ってる俺と同じこと言ってるよね？
0801デフォルトの名無しさん2016/02/16(火) 16:36:12.15ID:ALpXi/Iz
>>800
必要なとこで必要なツールを使う。これは当たり前だし同意見(その当たり前が難しいんだけど)。

しかし、モックをとりあげてSelenium批判を展開してたのはどこのどいつやら…
0802デフォルトの名無しさん2016/02/16(火) 16:53:49.81ID:/SRPqiEk
というか、モックモック言ってる奴は、mockが何なのか誤解してるのかもしれない。
0803デフォルトの名無しさん2016/02/17(水) 00:11:04.84ID:+7wgQGkt
出来る限り単体テストでやった方が割に合うってだけの話だろ。
馬鹿同士だからこんなくそ議論が続けられるんだな。
0804デフォルトの名無しさん2016/02/17(水) 01:37:21.08ID:quKaVBpr
>>803
いらっしゃい
0805デフォルトの名無しさん2016/02/21(日) 18:01:46.80ID:jZESqUY+
やー、どもども
0806デフォルトの名無しさん2016/02/21(日) 18:13:43.01ID:qV/hcbJu
いきなり人減ったな。全部自演か。
0807デフォルトの名無しさん2016/02/21(日) 20:38:51.46ID:2u0YlGhe
Seleniumは効率悪すぎるって言ってる俺はいるよｗ
人が少なくなったのは、反論できなくなったんじゃない？
0808デフォルトの名無しさん2016/02/21(日) 23:16:53.71ID:qV/hcbJu
>>807
技術についていけないお前まだいたのかｗｗｗ
0809デフォルトの名無しさん2016/02/22(月) 00:53:48.55ID:DrhQtD1z
何か言いたいことがあるなら前回の続きやっていいんだぜ？
0810デフォルトの名無しさん2016/02/22(月) 00:55:27.09ID:DTgVnuU9
>>809
>>803
0811デフォルトの名無しさん2016/02/22(月) 01:26:44.52ID:DrhQtD1z
>>810
ループさせるな。それは終わった話だ
0812デフォルトの名無しさん2016/02/23(火) 14:55:05.32ID:LZQYFwIM
seleniumで頻繁にログイン繰り返すとcaptcha表示されるサイトがあると思うんですけど対策どうしてます？
0813デフォルトの名無しさん2016/02/23(火) 15:08:03.16ID:It8Dq+Vv
>>812
マニュアルでアクセスすれば？
0814デフォルトの名無しさん2016/05/01(日) 15:37:12.01ID:tKi6j9CT
匿名通信（Tor、i2p等）ができるファイル共有ソフトBitComet（ビットコメット）みたいな、
BitTorrentがオープンソースで開発されています

言語は何でも大丈夫だそうなので、P2P書きたい！って人居ませんか？

Covenantの作者（Lyrise）がそういう人と話したいそうなので、よろしければツイートお願いします
https://twitter.com/Lyrise_al

ちなみにオイラはCovenantの完成が待ち遠しいプログラミングできないアスペルガーｗ


The Covenant Project
概要

Covenantは、純粋P2Pのファイル共有ソフトです

目的

インターネットにおける権力による抑圧を排除することが最終的な目標です。 そのためにCovenantでは、中央に依存しない、高効率で検索能力の高いファイル共有の機能をユーザーに提供します

特徴

Covenant = Bittorrent + Abstract Network + DHT + (Search = WoT + PoW)

接続は抽象化されているので、I2P, Tor, TCP, Proxy, その他を利用可能です
DHTにはKademlia + コネクションプールを使用します
UPnPによってポートを解放することができますが、Port0でも利用可能です(接続数は少なくなります)
検索リクエスト、アップロード、ダウンロードなどのすべての通信はDHT的に分散され、特定のサーバーに依存しません
ｖ
0815デフォルトの名無しさん2016/08/05(金) 14:15:37.87ID:jqFTRyEe
>>1
「テストしにくいから、コードを書き直させる」
という答えは反則?
0816デフォルトの名無しさん2016/08/12(金) 22:09:42.14ID:IYlYCot4
テストファーストは幻想
0817デフォルトの名無しさん2016/08/14(日) 00:44:30.73ID:XFB5YkDY
幻想だろうと具体仕様・テストがない悪夢よりは良い

>>815
反則じゃないだろうけど糞の役にも立たない答え
0818デフォルトの名無しさん2016/08/15(月) 04:58:26.37ID:CjA54vMx
テストしにくいコードってのはパフォーマンスを求めた結果生まれたりするもので、
テストしにくいコードにしたら、パフォーマンスが犠牲になる。
0819デフォルトの名無しさん2016/08/15(月) 04:59:02.37ID:CjA54vMx
二行目修正）
テストしやすいコードにしたら、パフォーマンスが犠牲になる。
0820デフォルトの名無しさん2016/08/15(月) 10:17:43.11ID:GUZ7DBqH
メンテしやすいコードもそうかもな
JSONだけ返すシステムはいけてると思う
0821デフォルトの名無しさん2016/08/22(月) 03:40:32.65ID:+JfquTF3
>>817
ファーストにならない
セカンド、サードにはなるけどね
0822デフォルトの名無しさん2016/09/09(金) 23:51:53.46ID:qVZ/v3OG
テストせんで出せばいい
0823デフォルトの名無しさん2016/09/10(土) 07:33:56.91ID:XD8JXdoT
よくわからないが動かんぞ
と言われただけで原因特定して直せるなら大丈夫
0824デフォルトの名無しさん2016/09/10(土) 15:10:30.34ID:QUVRyXDh
よくわからないが落ちるぞ

だろ
0825デフォルトの名無しさん2016/09/10(土) 19:04:49.19ID:Jm2YrF8N
甘いな
ユーザーの期待(思い込み)通りに動かなかったもの全てだ
0826デフォルトの名無しさん2016/09/10(土) 20:12:43.76ID:vL431mpn
その期待は天気や機嫌によって変わるからな
0827デフォルトの名無しさん2016/09/12(月) 20:30:03.16ID:zvYimMXG
まずその地域で落雷があったかどうか確認する
落雷があったら瞬低があった事にする
0828デフォルトの名無しさん2016/11/14(月) 22:31:15.92ID:A2iFoZHP
コードのあっちこっちに絶対にありえないパラメータやら余剰チェック情報を
つけて自己チェックできるようにすればいい
0829デフォルトの名無しさん2016/11/16(水) 13:11:50.53ID:d7D9Ori4
テストしやすいデバッグコードを追加する。
0830デフォルトの名無しさん2016/11/23(水) 23:59:34.84ID:Cp58JRz9
実行が遅くてもとにかくテスト結果がわかる粒度でテスト書くしかない。
0831デフォルトの名無しさん2016/12/11(日) 09:33:11.58ID:G916gL+V
CallerMemberNameAttribute class
0832デフォルトの名無しさん2016/12/11(日) 20:43:14.42ID:RldCArWa
>>828
30年前にEiffelという言語があってだな……

Code Contractsは流行らなかったがインフラとしては浸透した

C++にConceptちゃんはもう入れてもらえないのか……
0833デフォルトの名無しさん2016/12/16(金) 23:00:52.69ID:sTWK9lm6
>>832
フレームワークやライブラリー内部までやらないと意味が無い
0834デフォルトの名無しさん2016/12/17(土) 12:29:12.08ID:dUpX2yrx
>>833
コードカバレッジ100%でないならテストの意味がないとか言っちゃうクチですか

形式的な型チェック・nullチェック・範囲チェック書くなら
機械にも分かりやすく書いといた方がいいよね
くらいの「軽さ」じゃないと使えないよ
0835デフォルトの名無しさん2016/12/17(土) 12:46:09.85ID:SZHJDyPT
コードカバレッジ100%の方が意味ないよな。
0836デフォルトの名無しさん2016/12/17(土) 12:50:54.32ID:nqKjNIE4
100%に意味がないというならカバレッジ自体がそもそも指標として役に立たないって事だけど
0837デフォルトの名無しさん2016/12/17(土) 13:56:17.34ID:FHGzAvIJ
カバレッジはテストしてないところを見つけ出すためのツール
カバレッジを取っていない所は、テストがろくに行われていない。
0838デフォルトの名無しさん2016/12/17(土) 14:25:03.47ID:FHGzAvIJ
テストをすることに意味がある。
カバレッジ100%っていうのは
テストをすれば自然と達成できる程度のもの。

カバレッジ100%が意味が無いというのは
100%程度では意味がないということ。
それ以上やらないといけない。
0839デフォルトの名無しさん2016/12/17(土) 20:23:11.38ID:+uiZTdOO
カバレッジ100%つーてもC0とパスカバレッジでは大違いだわな
0840デフォルトの名無しさん2016/12/18(日) 00:12:13.97ID:aCKcGLhu
Cobertura で、カバレッジ中毒にならないように

命令網羅 C0 : 100%
分岐網羅 C1 : 90%
0841デフォルトの名無しさん2016/12/18(日) 23:37:24.89ID:XDWplpRq
まあ実際、どんなデータ値を突っ込んだかのが大事だったりする。
クリティカルな部分の絶妙なテストデータの設定というのがテストの腕の見せ所。
0842デフォルトの名無しさん2016/12/19(月) 00:33:42.24ID:qHCxQ2k+
>>841
ほんそれ。
カバレッジ100%に囚われてprivateなメソッドに対して直接テストコード書いたり、実行パスを通すだけで適切なassertionが無かったりとか、本当に無意味
0843デフォルトの名無しさん2016/12/21(水) 08:14:56.80ID:JI84hN1L
>>842
メソッド全部publicにしたわ
さらにクラスのままだとケースが爆発するから
全部staticにして挙動が引数でしか変わらないようにした

あれ?これよくね?
0844デフォルトの名無しさん2016/12/21(水) 12:35:58.20ID:kCrlwcjM
正解
0845デフォルトの名無しさん2016/12/26(月) 23:04:13.36ID:/iMD3zus
結局staticおじさんが正しいんだよ
0846デフォルトの名無しさん2016/12/26(月) 23:13:29.13ID:JfyrzkL7
>>845
そうバカにするけど
メンバ変数の状態を実際は把握しないといけないのに隠されてるのは痛い
というか意味が無い
余計な苦労を背負ってるだけで
0847デフォルトの名無しさん2016/12/26(月) 23:53:02.48ID:o+MLW/qO
メンバー変数を把握しないといけない状態になってることが間違ってる。
何のためのカプセル化だよ
0848デフォルトの名無しさん2016/12/28(水) 00:11:54.87ID:zQENRRN7
privateメソッドに対してテストをしたくなっったら
それはクラスが肥大化してる証拠だよ。

まず前提としてprivateメソッドなんてものは
ほとんど必要ありません。

長い処理があったとして、その中で汎用的な処理を
抜き出していったら、コードは短くなります。
短いのだからprivateな関数にするまでもありません。

それでもprivateメソッドが残ったとしたら
それはヘルパーメソッドとして別クラスに分離する。
別クラスの関数を呼ぶのだから、必然的にそのメソッドはpublicになる
そうすりゃそのメソッドだけでテストかけるだろう？

privateメソッドをテストしたいっていうのは、作り方が悪いんだよ。
0849デフォルトの名無しさん2016/12/28(水) 10:25:28.10ID:axkGkLLD
>>848
全く間違ってる。

> 長い処理があったとして、その中で汎用的な処理を
> 抜き出していったら、コードは短くなります。
> 短いのだからprivateな関数にするまでもありません。
メソッドの可視性は、コードの長短とは関係ない。
privateにすべきかどうかは、外部から隠蔽すべきかどうかのみによる。

> それでもprivateメソッドが残ったとしたら
> それはヘルパーメソッドとして別クラスに分離する。
そもそも外部から隠蔽すべき内容だからprivateにするのであって、
別クラスのpublicにするのは誤り。

ヘルパーメソッド（クラス）は、それが存在する意義がある場合に
作成すべき。

> privateメソッドをテストしたいっていうのは、作り方が悪いんだよ。
全くの思い込みにすぎない。
リファクタリングによっていくつかのprivateメソッドができたとき、
それをテストしたくなる場合もあるだろう。
0850デフォルトの名無しさん2016/12/28(水) 10:28:37.89ID:yWrP/m5t
>>849
一つだけ
>リファクタリングによっていくつかのprivateメソッドができたとき、
それをテストしたくなる場合もあるだろう

リファクタリングでテストを書き換えなければならないような自体が発生する事自体が基本的に間違ってる
0851デフォルトの名無しさん2016/12/28(水) 10:35:08.34ID:axkGkLLD
>>850
> リファクタリングでテストを書き換えなければならないような自体が発生する事自体が基本的に間違ってる
これも何かの先入観による思い込みに過ぎない。

あるメソッドを書いたときに循環的複雑度が大きくテストしづらいと感じたとき、
いくつかのメソッド抽出を行うことによって循環的複雑度が下がり、テストが
容易になることがある。
その変更により、抽出したメソッドをテストしたくなる場合もある。

あるいは、ヘルパーメソッド（クラス）として抽出すべき内容だとすれば、
その抽出したコードに対するテストを追加するだろう。

全てのコードとテストを書き終えたあとにリファクタリングを行うのではなく、
テストを書きながらコードも書きリファクタリングもするなら、そのようなことは
良くあること。
0852デフォルトの名無しさん2016/12/28(水) 10:38:17.17ID:axkGkLLD
さらに言うなら、自クラスのメソッドをテスト中にDIできるような言語であれば、
メソッドの抽出後テストを書き換えることはよくあるだろう。
（というか、DIを使うためにメソッドの抽出を行うということもある）
0853デフォルトの名無しさん2016/12/28(水) 10:45:52.86ID:yWrP/m5t
>>851
ねえわ
それこそ変な先入観による思い込み。

https://github.com/google/googletest/blob/master/googletest/docs/AdvancedGuide.md#testing-private-code
0854デフォルトの名無しさん2016/12/28(水) 10:49:03.53ID:axkGkLLD
以上、「privateメソッドをテストしたくなることもある」ケースの説明をしたが、
privateメソッドに対するテストをするのは全くお勧めできない。

テストは外部から見える範囲でやらないと、すぐにテストが壊れてしまう。

その意味で、自分が書いたコードをDIをするテストも非常に壊れやすい状況にあり、
それも実はお勧めできない。
このスレの意義に従っていうなら、DIしたい場合はコンストラクタDIかsetter DIが
良い。

>>853
どこが思い込み？
0855デフォルトの名無しさん2016/12/28(水) 10:55:05.67ID:yWrP/m5t
>>854
最後のコメントで160度ぐらい方向変わったな…
>リファクタリングでテストを書き換えなければならないような自体が発生する事自体が”基本的”に間違ってる
と俺は言ったんだがそれがどう何かの先入観による思い込みなのか先に示してくれない？
0856デフォルトの名無しさん2016/12/28(水) 11:07:42.77ID:QIn62sNS
1行で要約するとprivateはテストする意味ない
0857デフォルトの名無しさん2016/12/28(水) 11:08:14.56ID:axkGkLLD
>>855
別に喧嘩するつもりはないので、気分を害したことは先に謝っておく。

リファクタリングする前のテストが、リファクタリング後もPassしなければならないのは
その通り。

しかし、リファクタリングの結果テストを書き換えることは良くある。

メソッドの抽出の例だと、privateメソッドとして抽出するのではなく、publicメソッドとして
抽出することもある。
また、クラスとして抽出する場合もある。
前述したように、そもそもテストしやすくする目的でリファクタリングすることもある。

そのような場合は、リファクタリング後にテストを変更するのでは？
0858デフォルトの名無しさん2016/12/28(水) 11:14:40.72ID:UhH7SrSp
テストを外部仕様の保証とみなす考え方からすればそもそもprivateなメソッドのテストは
不要なんだろうが、べつにテストを書きたい理由がそれに限られるわけでもないだろう。
0859デフォルトの名無しさん2016/12/28(水) 11:26:16.21ID:yWrP/m5t
>>856
直接テストする必要は基本的にない。
カバレッジとかを見てこのprivate関数を通るテストが弱いなとなったときにpublicメンバーを通じてそこを通るようなテストコードを書くことは否定しないし、むしろいい。

>>857
外部クラスとして抽出するとかテストしやすく変更するとかであればそれはテストの変更というより、テストを新規で追加する事になると思うんで、そこは意味的に分けて欲しいかな。
0860デフォルトの名無しさん2016/12/28(水) 23:06:39.02ID:zQENRRN7
>>849
> privateにすべきかどうかは、外部から隠蔽すべきかどうかのみによる。

ヘルパークラスを作れば外部から隠蔽しない理由になるだろ

privateのままにしておくからテストできないんだよ。
そういうものは隠蔽すべき理由を無くしてpublicにしてしまえと言ってる。
0861デフォルトの名無しさん2016/12/28(水) 23:10:39.71ID:zQENRRN7
言っておくけどprivateのものを処理を全く変えずにpublicにしろって話じゃない。

テストをしたくなるほどprivateメソッドが複雑になるのであれば、
そのprivateメソッドをヘルパー関数の形で汎用化しろって話。

そうすれば、対象のクラスそのものではなくてヘルパークラスのみで
テストできるようになる。そしてクラスはシンプルになる。
0862デフォルトの名無しさん2016/12/28(水) 23:18:43.37ID:zQENRRN7
>>857
> そのような場合は、リファクタリング後にテストを変更するのでは？

これも関連する話。まずリファクタリング後にテストを変更するのは当然

まず対象のクラスに対してテストを書く。そしてリファクタリングをする。
この時、汎用的な処理をヘルパークラスや親クラスとして抽出する。

ここまででテストを変更することはないが、
次に対象のクラスにあったテストのうち、ヘルパークラスや親クラスに分離したものは、
対象のクラスのテストではなくて、ヘルパークラスや親クラスのテストとして移動する

ヘルパークラスや親クラスでテストしている内容を、
それを使用している対象クラスでもやる必要はない。

具体的に言うと、あるモデル、例えばUserモデルクラスにsaveメソッドを作ったのであれば
そのsaveメソッドのテストを書くのは当然だが、そのsaveメソッドが親クラス
（例えばRailsで言えばActiveRecord::Baseクラス）にあるものならば、
Userモデルクラスでsaveメソッドのテストをする必要はない。


こうやってヘルパークラスや親クラスに処理を移動して、それに対するテストを書くことで
それを使用している部分ではテストが不要という状態を作り上げることが重要
0863デフォルトの名無しさん2016/12/30(金) 10:52:00.55ID:NmKeqyEh
過剰な反応だな。
話の軸がずれてるわけでもないのに。
0864デフォルトの名無しさん2016/12/30(金) 13:04:19.38ID:66Kkldk7
これを過剰だと思うのは
理解してない証拠
0865デフォルトの名無しさん2016/12/30(金) 13:14:46.99ID:B6h0Vr0u
自分が信じる教義に帰依させようと一所懸命な感じ。
0866デフォルトの名無しさん2016/12/30(金) 13:17:22.62ID:66Kkldk7
まあどちらにしろ何も言えないっていうのは
そういことだとしか思われるだけ
0867デフォルトの名無しさん2016/12/31(土) 23:01:17.34ID:EoEUSLSH
どっちもテストしやすい単位に切り出そうっていう話しかしてないのに、
俺正しい言いたい方向に議論を伸ばしちゃってるのがね。。
0868デフォルトの名無しさん2017/01/01(日) 10:37:28.98ID:h0NhlmdK
privateな関数が外部のテストコードからアクセスできないのは仕組として仕方ないとして、
それを「(設計を見直さない限り)テストすべきではない」と因果をひっくり返しているところに
論理の飛躍があるな。
0869デフォルトの名無しさん2017/01/01(日) 13:22:56.29ID:dt63qbz9
すべきじゃないよ
それをするとテストが失敗するからリファクタリングがやりづらくなる
0870デフォルトの名無しさん2017/01/01(日) 13:28:57.29ID:yOnXwyd5
>>868
いや、そうではないよ。

そもそもテストしにくいコードっていうのは
設計が悪いコードだから。
0871デフォルトの名無しさん2017/01/01(日) 13:31:17.20ID:yOnXwyd5
まあ俺だけが言ったところで信用出来ないだろうから

http://dev.classmethod.jp/testing/10_errors_about_unit_testing/
> 3.テスト対象が完璧な設計であるという勘違い
>
> ユニットテストを実践することによりプロダクションコードが
> 適切に修正されていく状態でなければなりません。
>
> ユニットテストの重要な目的のひとつに「テスト対象クラスやメソッドの
> 使用感を把握する」ことがあります。机上の設計やフィーリングだけで
> 書いたコードは、使ってみての違和感や使いにくさに気付き難いものです。
> それらの使用感は、実際に利用してみてはじめて気付きます。
> だから、テストコードを書くことで実際に利用してみます。これはサンプルコードを書く事に他なりません。
>
> サンプルコードを書くと、「これは使いにくい」と感じたり、
> 「これはこうした方が使いやすい」と感じたりします。それはユニットテストの
> 大きな効果です。もし、使いにくいと感じたならば、すぐにテスト対象を修正します。
> テスト対象が完璧な設計で変更する余地が全く無い、または変更してはならないのでは、
> ユニットテストを行ってもストレスしか溜まらないでしょう
0872デフォルトの名無しさん2017/01/01(日) 14:10:11.37ID:NwoHZB6Y
>>868 に賛成だな。
もう10年以上xUnit使った開発しているが、privateもテストできるならテストしたほうがいい。
変更したら、テストも変更すればいいだけ。言い訳にならない。
0873デフォルトの名無しさん2017/01/01(日) 14:16:32.12ID:yOnXwyd5
「privateだからテストしてはいけない」という意見はそもそも的外れで
テストすべきものがprivateという状態ができたら
それは設計がおかしいと気づかないといけない。

「privateだからテストしてはいけない」は単なる思考停止で
privateをテストしたいのは設計がまずいからだね、設計をなおそう。
という流れにならなければいけない。
0874デフォルトの名無しさん2017/01/01(日) 14:18:48.00ID:yOnXwyd5
もちろん「設計がまずい」というのは
privateをpublicに変えるという意味じゃない。
そんなの単なる可視性の違いでしかない
可視性を変えたところで設計は何も変わっていない。
0875デフォルトの名無しさん2017/01/01(日) 14:35:26.78ID:NwoHZB6Y
テストすべきかどうか？
コードがあれば、それはテストすべき。
テストするべきでないコードなんて存在しない。
0876デフォルトの名無しさん2017/01/01(日) 14:39:40.84ID:yOnXwyd5
>>875
今話をしてるのは関数単体でテストするかどうかの話だから
話の前提にすら辿りつてない人は話に参加しないでもらおうか？
0877デフォルトの名無しさん2017/01/01(日) 15:01:31.22ID:T039qKRQ
1行で要約するとprivate単体でテストする意味ない
0878デフォルトの名無しさん2017/01/01(日) 15:03:38.47ID:yOnXwyd5
private単体でテストしたいと思ったら設計に問題があるので
設計を変えることで（privateを自然な形でpublicなメソッドにして）
テストをする。という流れ
0879デフォルトの名無しさん2017/01/01(日) 15:05:17.59ID:yOnXwyd5
でそのために使われるテクニックに、
継承構造を取り入れることで親クラスのpublic（protected？）にする方法と
ヘルパークラスを作る方法がある。
0880デフォルトの名無しさん2017/01/01(日) 15:09:52.61ID:NwoHZB6Y
>>876
あーあ、やっぱ君は話をすり替えることしかできない無能だね。
関数単体だろうが、その関数がパブリックだろうがプライベートだろうが、
そこにコードがある限りテストはするべきだ。

プライベート単体でテストしたいかどうかという条件が愚問なんだよ。
プライベート単体だろうが、そこにコードがあればテストすべき。
設計以前の問題だ。プログラマ失格。
0881デフォルトの名無しさん2017/01/01(日) 15:13:16.31ID:yOnXwyd5
ほう（苦笑）

では聞くが、privateがテストできないときはどうするんだ？
privateもテストできるならテストしたほうがいいが
テストできないときはどうするんだ？
0882デフォルトの名無しさん2017/01/01(日) 15:21:34.76ID:h0NhlmdK
>>878
テストできないのはprivateだからであって、テストするにはpublicにすればよい。

>そもそもテストしにくいコードっていうのは
>設計が悪いコードだから。

>private単体でテストしたいと思ったら設計に問題があるので

この設計の良し悪しに絡めた解釈が根拠も意味もない部分。
0883デフォルトの名無しさん2017/01/01(日) 15:26:42.90ID:yOnXwyd5
> テストできないのはprivateだからであって、テストするにはpublicにすればよい。
privateにしたのには理由がある。その理由をそのままにpublicにすることはいけない。

まずprivateにした理由を排除することが先。

それを設計を修正することにほかならない
0884デフォルトの名無しさん2017/01/01(日) 15:27:05.95ID:yOnXwyd5
それは設計を修正することにほかならない
0885デフォルトの名無しさん2017/01/01(日) 15:51:20.40ID:NwoHZB6Y
>>881
それは単なるテストを実施する上での技術的問題であって、
テストすべきかどうかとは関係ないし、
設計の良し悪しとも関係ない。

何度言われたらわかるんだこの能無しID:yOnXwyd5 は
ばーか
0886デフォルトの名無しさん2017/01/01(日) 15:51:45.67ID:GauGkBvY
内部の変更によってテストが壊れるべきじゃない。

https://github.com/google/googletest/blob/master/googletest/docs/AdvancedGuide.md#testing-private-code

リファクタリングしたらテストが壊れたから修正しましたじゃダメなんだよ
0887デフォルトの名無しさん2017/01/01(日) 15:52:40.75ID:yOnXwyd5
>>885
質問に答えろよ

テストできないときはどうするんだ？
0888デフォルトの名無しさん2017/01/01(日) 15:53:01.36ID:GauGkBvY
俺には ID:NwoHZB6Y がバカに見えるよ
0889デフォルトの名無しさん2017/01/01(日) 15:54:58.29ID:yOnXwyd5
>>886
当たり前すぎて何が言いたいのかわからんが、
さらに↓これを理解できるレベルまで来ないとだめだよ。

http://higelog.brassworks.jp/1941

テストコードにもリファクタリングが必要

・昔はテストコードがメンテ対象であるという意識が薄かった
・見てすぐ分かるテストコードがよいという考えからコピペコードが非常に多かった
・テストコードがたくさんあることによって動きが取りづらくなり、変更コストも上がる
・素早く動きたいがためにTDDしているのにそんな皮肉な結果になってしまう
・たくさん書くのではなく必要十分書くことが大切
・書き散らすと「テストケース爆発」を起こす
・テストコードもメンテし続けるためにリファクタリングして行く必要がある
0890デフォルトの名無しさん2017/01/01(日) 15:58:45.71ID:NwoHZB6Y
テストできないならできませんと正直に認めれば良いだろw
それを「設計が悪いんだ！」とか「テスト必要ない」とか
クソみたいな言い訳で誤魔化すようなバカはプログラマ失格。
ソフトウェア業界から去ってくれ。
迷惑以外の何物でもないから。
0891デフォルトの名無しさん2017/01/01(日) 15:59:25.89ID:yOnXwyd5
>>890
コードがあれば、それはテストすべき。
テストするべきでないコードなんて存在しない。
0892デフォルトの名無しさん2017/01/01(日) 16:00:21.23ID:NwoHZB6Y
>>891
やっとわかったかバーカ
0893デフォルトの名無しさん2017/01/01(日) 16:00:22.54ID:yOnXwyd5
>>890
privateもテストできるならテストしたほうがいいが
テストできないときはできません
0894デフォルトの名無しさん2017/01/01(日) 16:00:58.17ID:yOnXwyd5
>>892
お前が言ったんだぞ

privateもテストできるならテストしたほうがいいが
テストできないときはできませんと認めればいいって


お前発言が矛盾してるぞｗ
0895デフォルトの名無しさん2017/01/01(日) 16:01:56.35ID:NwoHZB6Y
自分の能力の不足を設計者のせいにしたり、テストなんて不要とか言ったり。
技術者として恥ずかしいとは思わないのかね。
まあ技術者以前に人間として失格だわな。
0896デフォルトの名無しさん2017/01/01(日) 16:02:38.47ID:yOnXwyd5
ID:NwoHZB6Yには、もう一回言わないと理解できないのかな？

876 名前：デフォルトの名無しさん[sage] 投稿日：2017/01/01(日) 14:39:40.84 ID:yOnXwyd5 [5/15]
>>875
今話をしてるのは関数単体でテストするかどうかの話だから
話の前提にすら辿りつてない人は話に参加しないでもらおうか？
0897デフォルトの名無しさん2017/01/01(日) 16:03:03.84ID:GauGkBvY
>>889
その当たり前の事をID:NwoHZB6YとID:h0NhlmdKは理解できてないみたいだから言ってんだよ。


>テストコードがたくさんあることによって動きが取りづらくなり、変更コストも上がる

これで変更コストが上がるってことは外部に公開してるインターフェースが変わるってことだからプロジェクトの性質によっては変更コストが軽くなるべきじゃ無いとおもうな。
特に汎用的に使われるライブラリを作ってる場合は。
0898デフォルトの名無しさん2017/01/01(日) 16:03:30.26ID:yOnXwyd5
テスト不要なんて（ ID:NwoHZB6Y以外）誰も言ってないよなぁｗ
0899デフォルトの名無しさん2017/01/01(日) 16:03:49.72ID:NwoHZB6Y
>>894
ねえ、君、気が狂った？
俺は最初からそう言っている。
(1) プライベートだろうがそこにコードがあればテストすべき。
(2) 技術的問題でテストできないことを設計のせいにするな。
(3) 技術的問題でテストできないのにテスト不要なんて誤魔化すな

わかったか。
0900デフォルトの名無しさん2017/01/01(日) 16:04:54.58ID:NwoHZB6Y
>>898
うそつき。おまえみたいのがプロジェクトを炎上させるんだよ。クズが。
0901デフォルトの名無しさん2017/01/01(日) 16:05:00.15ID:yOnXwyd5
>>899

だからお前の発言が矛盾してると言ってる

お前はこうも言ってるだろ

> privateもテストできるならテストしたほうがいいが
> テストできないときはできませんと認めればいい
0902デフォルトの名無しさん2017/01/01(日) 16:05:47.82ID:yOnXwyd5
「privateもテストできるならテストしたほうがいい」っていう発言は
privateでテストできない場合があると認めてる証拠
0903デフォルトの名無しさん2017/01/01(日) 16:06:51.92ID:yOnXwyd5
872 名前：デフォルトの名無しさん[sage] 投稿日：2017/01/01(日) 14:10:11.37 ID:NwoHZB6Y [1/9]
>>868 に賛成だな。
もう10年以上xUnit使った開発しているが、privateもテストできるならテストしたほうがいい。


↑ここでいってるなｗ
0904デフォルトの名無しさん2017/01/01(日) 16:08:31.25ID:yOnXwyd5
>>899

(1) コードがあればテストすべき。
(2) 技術的問題でテストできない
(3) 技術的問題でテストできない

テストすべきなのかできないのかはっきりしろよｗｗｗ
0905デフォルトの名無しさん2017/01/01(日) 16:11:48.88ID:NwoHZB6Y
>>903
論点を理解できないバカ？
脳の病気がなおるまでソフトウェア業界に近寄らないでくれる？
バイバイ
0906デフォルトの名無しさん2017/01/01(日) 16:14:59.94ID:yOnXwyd5
典型的な負け犬の遠吠えぇぇwｗｗｗｗ
0907デフォルトの名無しさん2017/01/01(日) 16:16:07.67ID:yOnXwyd5
じゃ話を俺の話しに戻すかね

873 自分：デフォルトの名無しさん[sage] 投稿日：2017/01/01(日) 14:16:32.12 ID:yOnXwyd5 [3/22]
「privateだからテストしてはいけない」という意見はそもそも的外れで
テストすべきものがprivateという状態ができたら
それは設計がおかしいと気づかないといけない。

「privateだからテストしてはいけない」は単なる思考停止で
privateをテストしたいのは設計がまずいからだね、設計をなおそう。
という流れにならなければいけない。
0908デフォルトの名無しさん2017/01/01(日) 16:20:10.01ID:GauGkBvY
>>905
じゃあまず論点はっきりさせてくれない？
俺にはお前が

・privateメンバーはpublicメンバーを通してテストするべきでprivate単体でテストするべきではない

に文句付けてるように見えるけど

>>907
お前はちょっと落ち着け
0909デフォルトの名無しさん2017/01/01(日) 16:26:22.18ID:yOnXwyd5
>>908
面白いおもちゃ見つけたのに
落ち着いていられるかｗ
0910デフォルトの名無しさん2017/01/01(日) 20:19:09.67ID:h0NhlmdK
>>897
それは安定していないインターフェースをテストする場合の問題であって、可視性とは別だが。
0911 【豚】 【40円】 2017/01/01(日) 21:13:27.87ID:9MvoRZrQ
もちのように延びるスレ
0912デフォルトの名無しさん2017/01/01(日) 21:18:38.46ID:24uPORqY
正論だろうが詭弁だろうが
id真っ赤にしてる時点でプログラマに向いてない
0913デフォルトの名無しさん2017/01/01(日) 22:02:00.34ID:yOnXwyd5
> id真っ赤にしてる時点でプログラマに向いてない
その根拠は？

理由を論理的に説明できなければプログラマには向いてないｗ
0914デフォルトの名無しさん2017/01/01(日) 23:43:57.00ID:y/0zTBoG
良いテストになってますね^^
0915デフォルトの名無しさん2017/01/02(月) 16:38:48.98ID:xB/0AlnY
>>886
https://github.com/google/googletest/blob/master/googletest/docs/AdvancedGuide.md#testing-private-code
を読んで、「プライベートだからテストしなくていいもん」と思ったのなら、
中学校の英語からやりなおしたほうがいい。
0916デフォルトの名無しさん2017/01/02(月) 16:48:25.64ID:/uJ3gdXu
>>915
誰がそんな事言ってんだよ
0917デフォルトの名無しさん2017/01/02(月) 20:15:22.75ID:/uJ3gdXu
>>915
お前は思い込みの激しさをなんとかした方が良い
0918デフォルトの名無しさん2017/01/03(火) 07:33:18.02ID:Oj8nbLhF
>>915 のリンク先に書いてあるのは、
privateなメンバーはその言語で可能な全ての手を尽くして
単独のメソッドとしてテストしろ
ということだな。
0919デフォルトの名無しさん2017/01/03(火) 07:51:04.59ID:f6cee8Pv
Google翻訳の精度上がったんだし、自信ないなら翻訳した方がいいよ

Testing Private Code

If you change your software's internal implementation,
your tests should not break as long as the change is not observable by users.
Therefore, per the black-box testing principle, most of the time you should test your code through its public interfaces.

If you still find yourself needing to test internal implementation code, consider
if there's a better design that wouldn't require you to do so. If you absolutely
have to test non-public interface code though, you can. There are two cases to consider:

Static functions (not the same as static member functions!) or unnamed namespaces, and
Private or protected class members

プライベートコードのテスト

あなたのソフトウェアの内部実装を変更した場合、変更がユーザによって観察されない限り、
テストは中断されるべきではありません。 したがって、ブラックボックスのテストの原則に従って、
ほとんどの場合、パブリックインターフェイスを使用してコードをテストする必要があります。

依然として内部実装コードをテストする必要がある場合は、そうする必要のない
優れた設計があるかどうかを検討してください。 しかし、非公開のインターフェイスコードを
絶対にテストしなければならない場合は、できます。 考慮すべき2つのケースがあります：

静的関数（静的メンバー関数と同じではない！）または名前のない名前空間
プライベートクラスまたは保護されたクラスメンバ
0920デフォルトの名無しさん2017/01/03(火) 07:55:02.34ID:f6cee8Pv
俺が最初に言ったとおりってことよ

> パブリックインターフェイスを使用してコードをテストする必要があります。

privateメソッドは直接テストしない。publicメソッドを通してテストするもの

> 内部実装コードをテストする必要がある場合は、そうする必要のない
> 優れた設計があるかどうかを検討してください。

そしてテストすべきものがprivateという状態ができたら
それは設計がおかしいと気づかないといけない。

privateをテストしたいのは設計がまずいからだね、設計をなおそう。
という流れにならなければいけない。
0921デフォルトの名無しさん2017/01/03(火) 08:46:36.02ID:q0Juw9L/
>>918
お前が中学校の英語から…というか翻訳サイト使っても解るのに何からやり直したらいいか解らないレベルでヤバいな
0922デフォルトの名無しさん2017/01/03(火) 08:48:25.07ID:q0Juw9L/
ネタにマジレスしてしまった…反省
0923デフォルトの名無しさん2017/01/03(火) 08:49:18.10ID:d67WhAVX
ということは、テストする必要がありそうなコードは
片っ端から public にしとけば、なんだかわからんが勝手に良い設計になってるぞ、
なんてことあるのかな？
0924デフォルトの名無しさん2017/01/03(火) 08:53:27.75ID:f6cee8Pv
>>923
上でも書いた気がするけどな

> 内部実装コードをテストする必要がある場合は、そうする必要のない
> 優れた設計があるかどうかを検討してください。

ってかいてあるだろ。設計を変えるんだよ。

privateをpublicにするのは可視性を変えただけで
設計は何も変わっちゃいない。

どういうふうに変えるかは>>848や>>862で書いたとおり
汎用的な処理をヘルパークラスや親クラスとして抽出するの
0925デフォルトの名無しさん2017/01/03(火) 08:54:18.13ID:q0Juw9L/
>>923
まず
・privateメンバーはublicメンバーを通してテストする
が大原則。それで足りない場合のみ他の方法を考える
0926デフォルトの名無しさん2017/01/03(火) 09:56:37.13ID:078nuCwR
プログラム設計の善し悪しとテスト技法がごっちゃになってる。
このスレでテストする側とすれば設計の善し悪しなんて知ったこっちゃないのよ。スレタイ読め。

例で考えよう。
private function numberOfFeet(動物) returns 脚の数
{
　if (動物 == 人) { return 2 }
　if (動物 == 犬) { return 4 }
　if (動物 == 猫) { return 4 }
　raise exception 知らない動物
}
っていう関数が既にあるとする。
人なら2, 犬猫なら4, それ以外では実行中断というテストになって、それ以外の結果が出るはずがないのを期待している関数で、
エンドユーザに影響がない限りにおいてはこれの中身がどう実装されていようと知ったこっちゃない。
つまり可視なテストコードからの実行結果も変化すべきではない。変化するとすればそれは private 関数内部のバグと見ていい。
このプライベート関数とセットになる可視テストでそこが保証できたら、この関数をどこで使ったとしても「改めてテストをする必要がないブラックボックス」にできるわけだ。

ただ、この後、生物学あたりで人の腕も前脚だ、つまり人の脚の数は4本だというように定義が変更になった場合を考えてみて。
人の脚を訊いたら4と返すようにしないといけないのはエンドユーザにも見えるような仕様変更だから
設計をそのままにするならテストも変更せざるを得ないというのは納得いただけるかと思う。
これはプログラム設計の時には思いもよらない変更だと思うからプログラマの非ではないが、対応する必要はある。
このスレではここまでの話で済ませればいい。

では脚の数を訊く関数を廃止して別の方法を採るのか、やはりそのまま行くのか、その設計がきれいなのか汚ないのかは別の話。
このスレでの興味はあくまで既存コードのテストなので、まずはその時点で考え得るバグが検出できたらそれでいいわけ。
設計の善し悪しの話がしたいのであれば別スレ建ててやってくれ。
0927デフォルトの名無しさん2017/01/03(火) 10:01:10.08ID:078nuCwR
って、もうスレ残りほとんどないね。どうせもう >>1 もいないだろうから、どうぞやっちゃってください。
0928デフォルトの名無しさん2017/01/03(火) 10:07:16.02ID:q0Juw9L/
>>926
ユーザーからしたらprivate関数であるnumberOfFeet自体実装されてようがされてまいが関係ない。numberOfFeetを見直して結果が変わろうがその関数自体削除しようがpublicメンバーを使用して操作した結果が変わらなければ関係ないんだよ。
0929デフォルトの名無しさん2017/01/03(火) 14:09:22.70ID:Oj8nbLhF
>>919
そこ、場所が違うw
Private Class Members
Private class members are only accessible from within the class or by friends.
To access a class' private members, you can declare your test fixture as a
friend to the class and define accessors in your fixture. Tests using the fixture
can then access the private members of your production class via the accessors
in the fixture. Note that even though your fixture is a friend to your production
class, your tests are not automatically friends to it, as they are technically
defined in sub-classes of the fixture.

Another way to test private members is to refactor them into an implementation
class, which is then declared in a *-internal.h file. Your clients aren't allowed to
include this header but your tests can. Such is called the Pimpl (Private Implementation)
idiom.

Or, you can declare an individual test as a friend of your class by adding this line
in the class body:

の辺りだ。ほら、サル丸出しで自動翻訳にかけて読んでみろw
0930デフォルトの名無しさん2017/01/03(火) 14:11:26.31ID:q0Juw9L/
>>929
いや、お前はなんで前提を無視すんの？
0931デフォルトの名無しさん2017/01/03(火) 14:11:34.35ID:Oj8nbLhF
有名組織が書いたものを最初のとこだけちょこっと読んで誤解した挙句、
金科玉条のように「privateメンバーは内部構造だからテストしちゃいけない！」
とか言い出すのって技術者としてすごく恥ずかしいことだからね。

特にテストエンジニアとしては全く適性がないから、さっさと業界から消えてくれ。
0932デフォルトの名無しさん2017/01/03(火) 14:11:54.17ID:Oj8nbLhF
>>930
英語よめないの？
0933デフォルトの名無しさん2017/01/03(火) 14:16:55.37ID:Oj8nbLhF
内部構造とprivateメンバーの違いがわからないバカにはオブジェクト指向は難しすぎる。
エクセル方眼紙でも埋めテロ
0934デフォルトの名無しさん2017/01/03(火) 14:19:51.85ID:f6cee8Pv
>>926
private関数がテストしたいと思ってきたら
設計が悪いという話だったね。

この場合は、このprivate function numberOfFeetを
publicにしてテストするのではなくて設計を変えるってことだよ。

もちろんやり方はいくつもある。
もっともシンプルな解決方法ではないが
今回はヘルパークラスを作る方法で解決してみようか。

LookupTableクラスというものを作る。
このクラスは特定のキーを元に特定の値を返すクラスだ。
newの引数で対応するキーと値の組み合わせを渡すことができる。

lookup_table = new LookupTable(
0935デフォルトの名無しさん2017/01/03(火) 14:20:11.82ID:f6cee8Pv
間違えた >>934 は無視してください。
0936デフォルトの名無しさん2017/01/03(火) 14:20:35.82ID:q0Juw9L/
という感じで基本的な事も理解してない奴ということが周知出来たかと思うので、私は相手するのをやめます
0937仕切り直し2017/01/03(火) 14:30:37.06ID:f6cee8Pv
>>926
なかなかおもしろい例を出してくれたね。
その関数で対応する動物がもっと増えたとしよう。

private function numberOfFeet(動物) returns 脚の数
{
　if (動物 == 人) { return 2 }
　if (動物 == 犬) { return 4 }
　if (動物 == 猿) { return 4 }
　if (動物 == キジ) { return 2 }
　if (動物 == 猫) { return 4 }
　　：
　　：
　raise exception 知らない動物
}

いよいよ複雑になってきた。privateなnumberOfFeetをテストしたい。
となってきたら、設計が悪いって話なんだよ。

そもそもこの関数のテストはどうするか？ ↓このようにやるか？
assert( numberOfFeet(人) == 2 )
assert( numberOfFeet(犬) == 4 )
assert( numberOfFeet(猿) == 4 )
　：

あほらしい。これは実行コードの内容を単純に変換してテストコードに転記したにすぎん。
新たに対応する動物が増えたら、それに対応するコードを追加するだけの単純作業
いったいなんの意味があるというのか。
そこ（実行コード）にそう書いてあるんだから関数の実行結果はあきらかではないか。

カバレッジを100%にするためには必要？
それは "設計が悪いから" こうするしかなくなってしまってるんだよ
0938デフォルトの名無しさん2017/01/03(火) 14:30:58.17ID:f6cee8Pv
private関数がテストしたいと思ってきたら設計が悪いという話だったね。
この場合は、このprivate function numberOfFeetを
publicにしてテストするのではなくて設計を変えるってことだよ。

もちろんやり方はいくつもある。もっともシンプルな解決方法ではないが
今回はヘルパークラスを作る方法で解決してみようか。

LookupTableクラスというものを作る。
このクラスは特定のキーを元に特定の値を返すクラスだ。
newの引数で対応するキーと値の組み合わせを渡すことができる。

lookup_table = new LookupTable({a: 1, b: 2, c: 3})

さて、このLookupTable・・・のテストを書くとき、
動物が増えたら？などということを考える必要はない。
LookupTableは汎用的なクラスなのだからそこに動物は出てこないからだ。
では使う側はどうなるか？

data = {人: 2, 犬: 4, 猿: 4, キジ: 2, 猫: 4}
numberOfFeet = new LookupTable(data)

こういうコードを書くだろう。
テストはどうする？ ・・・答えは "不要" だ。

なぜならばLookupTableのテストはすでに書いているからだ。
おそらくこのコードは別のテストコード時に最低1回は通るだろう。
それでカバレッジは100%になる。いくら動物が増えたとしても
そのdataというデータ定義の行は通るのでカバレッジは100%のままだ。
0939デフォルトの名無しさん2017/01/03(火) 14:36:56.23ID:f6cee8Pv
これを手抜きやずるいやり方だと思うか？

元の設計のテストというのはデータが増えれば対応するテストを
増やすだけという単純作業だっただろう？

こんなのそもそもやる意味がない
データが変われば、それに応じて答えは変わる。
それだけのことだろう。

こういうのは、そもそもやらなくていいんだよ。

変数aに1を入れました。これ対応する変数aは1であるか？という
テストコードを書く意味はない。
テストすべき対象は実行するコードであってデータ定義はテストしない。

LookupTableという汎用的なクラスを作ることで実行するコードの中から
データ定義を分離させることで、少ないテストパターンでカバレッジ100%にしながら
テストコードを書くことができる。それが可能な設計に変更したからだ。

ということで、 テストしたくなってしまった
private function numberOfFeetは
悪い設計を正すことで存在が消えました。

ということでおしまい。
0940デフォルトの名無しさん2017/01/03(火) 14:49:28.12ID:f6cee8Pv
プログラム設計の善し悪しとテスト技法は密接に関係している。

というかprivate関数をテストする言語特有の裏技的テクニックは
テスト技法ではないんだがな。

プログラム設計が悪いと、テストが難しくなったりできなくなったりする。
private関数のテストもその一つで、private関数がテストしたいほど
複雑になったら、それは設計が悪いということだよ。

こういうのはprivateのまま頑張ってテストするんじゃなくて、
単純にpublicに変えるのでもなくて、
汎用的な処理をヘルパークラスや親クラスとして抽出する

テストしづらい → 設計が悪い → 設計を直す → テストを書く
こういう流れでなくてはいけない。



話は少し変わるが、設計を直すその途中で作成するリファクタリングを
するためだけに用いる一時的なテストコードに名前をつけたいね。

本来であればテストしづらいコードであってもテストコードは
あってしかるべきなんだが、多くの場合悪い設計のコードにテストコードはない。
だから新たにテストコードを追加する。しかしこのテストコードは
リファクタリング後にすぐにメンテナンスして、違う形になる。

だから一時的なテストコードになるんだよね。
0941デフォルトの名無しさん2017/01/03(火) 14:51:07.11ID:f6cee8Pv
ついでに次スレ用意した

テストしにくいコードをテストする方法 その2 [無断転載禁止]©2ch.net
http://echo.2ch.net/test/read.cgi/tech/1483422644/
0942デフォルトの名無しさん2017/01/03(火) 14:54:52.06ID:f6cee8Pv
あ、そうそう

リファクタリングを行うための一時的なテストコードであれば
単純にprivateをpublicに変えたり
private関数のテストコードを書くのもありだから。

このprivate関数へのテストはリファクタリングをしたあとの
テストコードのメンテナンスでなくなるという前提であれば
一時的にprivate関数へのテストコードを書くのはあり。
0943デフォルトの名無しさん2017/01/03(火) 15:02:35.23ID:Oj8nbLhF
>>936 の勝利宣言が秀逸w
おねがいだからこの業界から去ってね。
周囲が迷惑してるから。
0944デフォルトの名無しさん2017/01/03(火) 17:54:39.96ID:NG8bRimt
スレ立てるのは良いけどある程度埋めないと落ちちゃうよ
0945デフォルトの名無しさん2017/01/03(火) 17:59:37.26ID:f6cee8Pv
落ちたらまた立てるよ
0946デフォルトの名無しさん2017/01/03(火) 18:06:22.02ID:f6cee8Pv
仕方ないな。埋めといたよ
0947デフォルトの名無しさん2017/01/03(火) 18:22:23.46ID:NG8bRimt
乙
0948デフォルトの名無しさん2017/01/03(火) 19:19:53.91ID:Oj8nbLhF
埋め荒らしの自白か
0949デフォルトの名無しさん2017/01/03(火) 19:35:59.23ID:/ZQ7wvWM
>>938
新たにハッシュに追加した項目は、テストすべき

4・"4" など、型を間違えて書く場合があるから
0950デフォルトの名無しさん2017/01/03(火) 19:43:46.33ID:q0Juw9L/
>>949
それな。
カバレッジ100%でも適切なassertionが無ければ無意味な良い例
0951デフォルトの名無しさん2017/01/03(火) 20:14:50.68ID:q0Juw9L/
型安全な言語なら大丈夫だろというツッコミ入るだろうから先に言っておくけど、型だけでなく普通に数値を間違える可能性もあるので適切なassertionが必要。その点においてカバレッジ100%なんて意味はない。

コード見たら自明とか言ってたらそもそもテスト書く意味ねえから。コードは書いたとおりに動くだけなわけで。
0952デフォルトの名無しさん2017/01/03(火) 22:28:17.83ID:f6cee8Pv
>>949
> 新たにハッシュに追加した項目は、テストすべき

いらない。やる価値がない。
0953デフォルトの名無しさん2017/01/03(火) 22:35:23.75ID:f6cee8Pv
新たにハッシュに追加した項目は、テストすべきというのなら
そのハッシュをファイルから読み込む場合は、
設定しうるすべてのデータをテストすると言ってるようなもん。
0954デフォルトの名無しさん2017/01/03(火) 23:14:59.37ID:k9drGvKD
>>953
ファイルから読み込む場合とクラス内にデータとして埋め込むのは設計からして違うし、
ファイルから読み込む場合も想定するデータは全てテスト書くに決まってるじゃん？
0955デフォルトの名無しさん2017/01/03(火) 23:55:01.89ID:k9drGvKD
>926 のprivate関数をテストやりづらいからという理由だけでファイルから対応表を読み込むように変更するというのはバカの所業というのに誰も異論ないよね？
0956デフォルトの名無しさん2017/01/04(水) 01:34:37.57ID:M78fqhv6
>>954
想定するデータ＝すべての動物
書いてみてよ
0957デフォルトの名無しさん2017/01/04(水) 01:35:26.99ID:M78fqhv6
>>955
これのどこがファイルからデータ読み込んでるの？

data = {人: 2, 犬: 4, 猿: 4, キジ: 2, 猫: 4}
numberOfFeet = new LookupTable(data)

いいからこのコードのテストを書いてみて。
0958デフォルトの名無しさん2017/01/04(水) 01:40:37.97ID:M78fqhv6
当たり前だけどさ、単なる変数定義のテストを書く意味は無いんだよね。

テスト初心者がよくやる意味がないテスト例

実行コード
data = {a: 1, b: 2, c: 3}

テストコード
assert(data, {a: 1, b: 2, c: 3})

こんなのね。さらにマヌケなのが、実行コードからコピペして
テストコードを作るｗ

こういうのは全く意味がない。dataにそのように定義しているのだから
dataにその値が入っているのは当たり前。

こういうのはやる意味がないし、やる必要がない。
逆に言えば、やる必要がないコードにすることで
意味がないテストコードを減らすことができる。
0959デフォルトの名無しさん2017/01/04(水) 01:45:12.40ID:M78fqhv6
時間は有限なのだから、テストもやる価値があるものだけやって
やる価値が無いものは、省略しなければいけない。

で、慣れた人は意図的にやる価値が無いものを増やして
本当に重要なやる価値があるテストを
必要最小限に絞り込むことができる。
0960デフォルトの名無しさん2017/01/04(水) 05:34:38.96ID:H7YeB4ee
>>956
じゃあ”すべての動物”の定義からやってくれないとね
>>957
クラスの内部実装に埋め込むのがファイルから読み込むのと変わらないと言ってるように見えたから念のため確認しただけだよ
そしてnumberOfFeetはprivate関数なのだからそれに対して直接テストする意味はないと何度も言ってる
publicインターフェースとその仕様が定義されないとテストを書く意味がない。
俺が勝手にそれを定義して書いてもいいけど、このスレ勝手にオレオレ定義で言ってもない事に対して反論して収拾つかなくなってるように見えるからそれこそそんな無駄なことやりたくねえわ
0961デフォルトの名無しさん2017/01/04(水) 05:43:05.97ID:M78fqhv6
> じゃあ”すべての動物”の定義からやってくれないとね

現在発見されているすべての動物
0962デフォルトの名無しさん2017/01/04(水) 05:44:23.06ID:M78fqhv6
> そしてnumberOfFeetはprivate関数なのだからそれに対して直接テストする意味はないと何度も言ってる

public関数経由でテストするんだろう？

> publicインターフェースとその仕様が定義されないとテストを書く意味がない。
お前がかけなかっただけ。

俺はpublicインターフェースを新たに作ることで
テストを書く方法を提示した。
0963デフォルトの名無しさん2017/01/04(水) 05:48:25.31ID:M78fqhv6
思ったんだけど、こういうのって数学の証明に似てるよな

数学3ケタの自然数が3の倍数の証明をする時、
すべての数学3ケタの自然数を3で割れるか
テストしなくちゃならないと思う人がいる

一方で「数学3ケタの自然数」表す式に
設計を変更することで、わずかの労力で
3で割り切れることをテストする人もいる。
0964デフォルトの名無しさん2017/01/04(水) 06:01:37.09ID:M78fqhv6
もう少しちゃんと書くかｗ
private function numberOfFeet(動物) returns 脚の数
{
　if (動物 == 人) { return 2 }
　if (動物 == 犬) { return 4 }
　if (動物 == 猿) { return 4 }
　if (動物 == キジ) { return 2 }
　if (動物 == 猫) { return 4 }
　　：
　　：
　raise exception 知らない動物
}

というコードがあったとき、これはprivateだからテストできないというやつがいる。
publicインターフェース経由でテストするのは間違いではないが、
おそらくそれは多数の意味のないテストになるだろう。

これを、俺は内部の設計を変更しLookupTableクラスを作った

data = {人: 2, 犬: 4, 猿: 4, キジ: 2, 猫: 4}
table = new LookupTable(data)
private function numberOfFeet(動物) returns 脚の数
{
　return table.get(動物)
}

LookupTableクラスのテストを書くのは簡単だから省略するが
動物をいくら増やしてもテストの数が変わらないことはわかるだろう。

残るテストはdataの中身が{人: 2, 犬: 4, 猿: 4, キジ: 2, 猫: 4}を確認するだけ
だが変数にその値を入れてるのだから、その値になるのは当たり前すぎて
テストの意味がない。こんなのはやる意味がない
0965デフォルトの名無しさん2017/01/04(水) 06:06:44.60ID:M78fqhv6
× 俺はpublicインターフェースを新たに作ることで
○ 俺はpublicインターフェースを持つクラスを新たに作ることで
0966デフォルトの名無しさん2017/01/04(水) 06:20:09.60ID:H7YeB4ee
>>961
お前はそのファイルに何を定義できるのか聞かれたら”現在発見されているすべての動物”と答えるのか？
色々な意味で頭悪そうだな…

>>962
はぁ、じゃあ俺は
>>926 の内部実装を持つクラスに
public int getNumberOfFeetOfCat()
という外部インターフェースが定義されてるとして話を進めるわ
assert(4==getNumberOfFeetOfCat());
とだけ書く
それでテストのコードカバレッジ100%にしろと言われたらprivate関数内のデッドコードの方を削除する。
0967デフォルトの名無しさん2017/01/04(水) 09:10:20.20ID:u2CyXKSE
>>963
言ってることが分からんが
もうらが必要ならテストすべきだし、必要じゃないなら統計で十分
証明済みならテストすら不要
0968デフォルトの名無しさん2017/01/04(水) 09:30:57.30ID:M78fqhv6
>>966
> assert(4==getNumberOfFeetOfCat());
> とだけ書く
> それでテストのコードカバレッジ100%にしろと言われたらprivate関数内のデッドコードの方を削除する。

仕様が変わってる。まったくつかえねーなｗ
0969デフォルトの名無しさん2017/01/04(水) 09:39:32.25ID:H7YeB4ee
>>968
仕様決めてないだろ？何言ってんだよ
0970デフォルトの名無しさん2017/01/04(水) 09:54:38.49ID:H7YeB4ee
private関数がいてそれがどの関数からも呼ばれていなかったらテストどころか、存在する必要がないからそのprivate関数は即刻削除すべき
当たり前の事だと思ってたけど、ID:M78fqhv6の中では何とかしてpublicメンバーに変更にしてテスト書くべきらしい。
0971デフォルトの名無しさん2017/01/04(水) 09:57:00.51ID:MZRDhGwM
必要なのは設定値の網羅テストじゃなくて、業務要件（要求仕様）の網羅テストだろ
それが足りてれば、将来想定外の問題が起きた時、要件定義の抜けということになり、テストの抜けとはならない
0972デフォルトの名無しさん2017/01/04(水) 13:24:05.05ID:H7YeB4ee
ID:M78fqhv6は自身満々に連投長文してる割に

If you change your software's internal implementation,
your tests should not break as long as the change is not observable by users.
Therefore, per the black-box testing principle, most of the time you should test your code through its public interfaces.

この部分の意味を理解していないように見える
0973デフォルトの名無しさん2017/01/04(水) 17:47:01.38ID:u2CyXKSE
privateまでテストしろとか聞いたことないよな
まともにプログラム組んだことないんじゃないの？
ケントベックすら涙目だな
0974デフォルトの名無しさん2017/01/04(水) 17:50:31.94ID:u2CyXKSE
まあ例外的に広範囲に呼び出し頻度が高いのはモジュール化してやるべきだろうが、
おそらくこいつはそう言う話はしてないだろう
0975デフォルトの名無しさん2017/01/04(水) 19:30:09.67ID:H7YeB4ee
ID:Oj8nbLhF とかケントベックの言ってること読んだら
>>全く適性がないから、さっさと業界から消えてくれ
って間違いなく言うだろうな…
0976デフォルトの名無しさん2017/01/04(水) 23:08:56.12ID:6PKdRVzk
private関数では、内部からの単体テストをするが、
public関数では、外からの入出力テストをする

public関数では、関数内の冒頭で、引数の妥当性チェックも行うが、

private関数では、内部実装を知っている人がコーディングするので、
そういう事を知っているのが前提なので、引数チェックもしない
0977デフォルトの名無しさん2017/01/05(木) 04:38:14.13ID:4wDE4Xcp
>>975
まるで逆だ。むしろID:Oj8nbLhFの主張はKentに近い。
なにより、Kentは「googleの人が言うからテストしなくていい」なんて発想が大嫌いだ。
0978デフォルトの名無しさん2017/01/05(木) 06:46:56.47ID:SvuiXrcs
>>977
大嘘つくなボケ死ね
0979デフォルトの名無しさん2017/01/06(金) 11:21:36.75ID:eKTGnv0Z
うるさいカス
0980デフォルトの名無しさん2017/01/06(金) 14:36:57.64ID:XtKi9eaG
ume
0981デフォルトの名無しさん2017/01/07(土) 12:18:28.69ID:HNCUhS1Q
先にこっち使え age
0982デフォルトの名無しさん2017/01/08(日) 00:19:17.41ID:oIuk3BCz
>>964
日本語では動いたけど他言語だと動かねーよとかありそうだし
一応やれって言われそうなパターンだぜ
0983デフォルトの名無しさん2017/01/08(日) 00:29:50.83ID:xMVs4RXt
>>982
必要ならやればいいじゃん？
でもやるのはLookupTableクラスだけでよい。
0984デフォルトの名無しさん2017/01/08(日) 00:32:24.71ID:xMVs4RXt
Kentもいってるようにprivateメソッドを直接テストしたいと
思ったら設計が悪いってことなんだよ。

設計を見直せば自然とpublicメソッドになるし、
それをテストすればいい。

設計を見直さないからだめなんだよ。
0985デフォルトの名無しさん2017/01/08(日) 04:51:02.71ID:v0X1COHT
>>983
privateメソッドに着目してテストしようとしてる時点でKentBeckの言ってることから外れてる。
publicメソッドがその仕様に合致してるかどうかのテストが必要。それ以上でも以下でもない。
publicメソッドのテストではその確認が難しい、privateの部分に対して直接テスト書きたくなったって時点でお前のいう設計見直しが必要。
そこは間違ってないが、そこだけ言うのは間違ってる
0986デフォルトの名無しさん2017/01/08(日) 09:15:06.60ID:iuCVJZyA
ケント様のおっしゃる通り！
ケント様の導きに従えばバグなんて出ない！

ひゃはははは腹いて～
0987デフォルトの名無しさん2017/01/08(日) 12:33:55.08ID:0mVP2hZ6
要検討
0988デフォルトの名無しさん2017/01/08(日) 14:43:42.44ID:xMVs4RXt
>>985
> privateメソッドに着目してテストしようとしてる時点でKentBeckの言ってることから外れてる。
外れてない。あんたはコードが成長するって言うことをわかっていない。

最初はシンプルでprivateにするのが妥当であっても、
仕様の変化や追加で、コードは変わっていく。

そのときにprivateをprivateのままテストをするんじゃなくて、
privateをテストしたいと思ったら設計が（今となっては）悪いってこと

だからまず先に設計を見直せという話。そうすれば自然とpublicに変わる。
privateをそのままpublicにするって話じゃない。
設計を見直すことでpublicに変わる。
0989デフォルトの名無しさん2017/01/10(火) 01:42:58.16ID:qNfJPVUt
テストの為にコードを書いてそう
0990デフォルトの名無しさん2017/01/10(火) 01:44:19.87ID:qNfJPVUt
訂正
テストでカバレッジ100%にするためにコード書いてそう
0991デフォルトの名無しさん2017/01/10(火) 02:53:22.33ID:eBcQpFvA
なんで100%にしなくていいかを考えればわかると思うけど
やるコストに対して効果が少ないから100%にする意味が無いってこと。

言い換えると効果が少ない部分に対しての
最大の手抜きがやらないってこと。

でもね、やらなくても、やるコストを減らすという方法もある。

privateをprivateのままテストするのはコストが高い。
なぜなら実際にテストしたい対象がpublicメソッドを介した奥深くに入り込んでいるから
奥深くに入り込んだメソッドはその他の多くのコードが含まれているためテストの条件も複雑になりがち

だからそういうのは設計を見直してpublicにすることでテストのコストを下げることができる。
0992デフォルトの名無しさん2017/01/10(火) 08:46:08.05ID:AG10ysu4
硬直してるね
そんなにprivateは悪設計だというのなら
private禁止にすればいいじゃんw
0993デフォルトの名無しさん2017/01/10(火) 14:13:13.65ID:s989ZmsY
外からみてprivateが無いのと一緒なら
外から見たpublic部分のインターフェース部分だけテストすればいい
じゃだめなん？
0994デフォルトの名無しさん2017/01/10(火) 17:47:46.88ID:/pTxhyNV
テストのためにprivateをpublicにするんだそうだ
0995デフォルトの名無しさん2017/01/10(火) 18:04:36.09ID:UBJKCQag
無駄な抵抗はよせ
0996デフォルトの名無しさん2017/01/10(火) 20:56:15.77ID:eBcQpFvA
>>992
> そんなにprivateは悪設計だというのなら

誰がそんなこと言ってるの？
わざと話をすり替えようとしてるのかな？

privateを "テストしようと思ったら" 悪設計だって
話をしてるよね？

卑怯だなぁ。どうせわざとだろうなぁ
0997デフォルトの名無しさん2017/01/10(火) 21:35:11.46ID:eBcQpFvA
結局のところ話しは簡単で
悪い設計は直しましょうってことなんだよね。
0998デフォルトの名無しさん2017/01/10(火) 21:47:34.39ID:WdYb5nlV
「悪い設計」の判断基準がおかしい
0999デフォルトの名無しさん2017/01/10(火) 22:02:47.20ID:eBcQpFvA
>>998
悪い設計の判断基準はいくつもあって、
その中の一つってだけなんだが？
1000デフォルトの名無しさん2017/01/10(火) 22:03:29.15ID:eBcQpFvA
別に悪い設計はprivateのテストがしたくなったときだけとは言ってない
10011001Over 1000Thread
このスレッドは１０００を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。
life time: 1732日 0時間 3分 38秒
10021002Over 1000Thread
２ちゃんねるの運営はプレミアム会員の皆さまに支えられています。
運営にご協力お願いいたします。


───────────────────
《プレミアム会員の主な特典》
★ ２ちゃんねる専用ブラウザからの広告除去
★ ２ちゃんねるの過去ログを取得
★ 書き込み規制の緩和
───────────────────

会員登録には個人情報は一切必要ありません。
月300円から匿名でご購入いただけます。

▼ プレミアム会員登録はこちら ▼
http://premium.2ch.net/

▼ 浪人ログインはこちら ▼
https://login.2ch.net/login.php
レス数が1000を超えています。これ以上書き込みはできません。