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

ここで言うテストっていうのは
ユニットテストみたいなものね。

人間がぽちぽち操作してやるテストじゃありません。

テストしにくいコードって何？

このスレッドは天才チンパンジー「アイちゃん」が
言語訓練のために立てたものです。

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

　　　　　　　　　　　　　　　　　　京都大学霊長類研究所

テストしやすいコードを書き換える

>>4
どのように書き換えるのですか？

俺がテストコードを書けないコードはない・・・

っていう厨2病のテストエンジニアが主人公の漫画でも小説でもいいから書いてくれ

>>5
コードが単体テストし難くなっている原因による

その単体テストがし難くいコードが具体的に示されるまでは、
テストし難い部分を切り分けるという極一般的で大雑把なアドバイスしかできない

よくわかんないけど>>1は首だ

UIは面倒くさい。毎回「どうやってテストするの？」って思う。

画像と比較すればいいのではないか？

>>9
マウス操作やキーボード操作、メッセージを発行を
スクリプトで自動制御するアプリを DL してくるか自作して、
それで GUI 部分をテストする

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

ついでにネットワーク処理のテストは、
たしか任意の負荷をかけられるテスティングツールがあったはず

>>11
もう少し具体的に言うと、
アプリ側にGUI操作する度にログを吐き出す仕組みを作っておき、
自動操作スクリプトで操作させた結果のログと期待するログとを比較する

ネットワーク越しにあるGUIで操作するものとか
自動でやるの厳しいよね

>>13
どうして？

>>1
レガシーコード改善ガイド

>>11 せれにうむとか

>>13
逆にネットワークから流れてくる同じデータ流せばいいから簡単そう

>>16
Web系ならそうっすね

人に頼む

>>19
高すぎる

テストしにくいコードって
・居眠りしてる間に小人さんが書いてくれた
・設計のバグ
・コーダーのバグ
とかのこと？

いまだにコーダーとか言ってる人は、Webデザイナーの人？

>>22
いや、写経するだけの人っているじゃん？

>>23
「写経」というのが、詳細な設計情報をただ単にコードに落とすというのを指してるとすると、
そんな詳細な設計書を書く所がいまだに存在するのかという疑問になる。

>>23
写経がなんだかわかりませんが。
とにかく、特殊な分野の人なんですね。

>>25
いや、そうでもないよ。
おそらく君が日常的に接しているソフトの大半はその写経で作られてる。

>>26
その写経とやらが具体的にどういう行為なのかわからんのだが、
詳しく説明してみてくれんかな

詳細な設計情報をただ単にコードに落とすというのを指してるとすると、

とすると？

「写経」というのが、詳細な設計情報をただ単にコードに落とすというのを指してるとすると、
コーダーとやらはその設計情報通りに単にコードに落としてるだけなので、
テストし辛いとしたらコーダーのせいではなく、設計者のせいだね。

>>26
君時代に取り残されてるよ
コーダってもうWeb業界でしか使わないよ

>>31
うん、そういう人たちはPGって呼ばれてるね。

Web業界のことは知らないけど。

>>24
詳細設計書と呼ばれる自然言語で書かれたゴミしか
生産できないバカの雇用を守るために存在するよ

オールグリーンだのコードカバレッジがどうのだの言っても
本質的にテストでは欠陥が存在しないことが証明できない
つまりこれからは形式的手法の時代だ

勿論そんな時代は来ないがな！

>>26
たとえば、写経してできたコードが
クイックソートのコードだとして、

そのクイックソートの詳細な設計書ってのは
どんなのだい？

今時クィックソートなんてコーディングしないよ。

多角形の細分化(一つの三角形を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;
}

法線が揃ってるかどうかをチェックすればいいんじゃないの？

法線ってどういう事？
全部同じ方向に回ってたんじゃ穴が開くんだけど。
あと、関数のテストだからテストコードの作り方で教えてもらえるとありがたいな。

>>38
「穴が開いたりすんだよね」 と言うが、
穴が開いたかどうかを君はどうやって認識してるんだ？

同義だが、正しい方向かどうかを「君は」何を以て判断してるんだ？

>>41
前者は出力した画像
後者は理屈(理論上の正しい計算式)

画像での確認だけど、ある頂点の組み合わせを指定して
三角形に穴が開くことは解っても、どんな頂点の組み合わせでも
穴が開かない事を確認するのは難しいんだよね。
結局後者の理屈だのみ。

>>42
> どんな頂点の組み合わせでも
> 穴が開かない事を確認するのは難しいんだよね。

本当に難しいのか？

細分化する前の多角形を塗りつぶした画像と、
細分化した後の全ての三角形を塗りつぶした画像は、
（細分化が正しく処理されれば）ぴったりと一致するのでないのか？

まぁ、効率を求めると、画像よりもハーフエッジの考え方を用いた方が良いんだけど、
思考の出発点としては画像を用いてもそれほど難しくない思うぞ

>>43
頂点座標の選び方次第で、辺のめぐり順が間違ってても、
一致することもあるんだよね

このケースではハーフエッジをどう使うの？

もしかしたら、誤解があるかも知れないから補足。
穴が開くってのは、陰面消去てきな話じゃなくて、
座標の誤差で三角同士の間に1〜2pixelぐらいの穴が
開くってことね。

>>46
それはそもそもアルゴリズムが間違ってるんじゃね？
表示部分で浮動小数の座標を受け付けないようになってるとか。

高速化と精度のため整数でやってるけど、理屈通り正しくやれば誤差は発生しないよ。
あと、ここで聞いてるのは、バグの潰し方じゃなくてテストの仕方ね。
>>38は正しく動くけど、式が正しいか検証するためのテストはどうしたらいいってのが本題です。

> 式が正しいか検証するためのテストはどうしたらいいっての
そんなもん、テストで検証することじゃなくてコードレビューでもして
チェックすることだとおもうが。
(テストで確認するとすれば、境界値の確認とかだろう)

テストってのは「これだけの動作確認をしたところ、問題ありませんでした」ってのを
示すためのものであって、それ以上のものではない。

じゃある範囲の座標で正しく動く事を保証するテストなら
1000x1000は保証するとして、1000x1000の座標全ての組み合わせを
試せばいいんでしょ。問題は、その結果確認を如何に自動化するかだけど

>>45
確認なんだが、細分化してできた全ての三角形について、
それをレンダリングするとき、頂点をたどる方向は同じ順だよな
たとえば全て反時計回りに頂点をたどるとか
（たとえば OpenGL を使って三角形をレンダリングするならそうなる）

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

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

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

もし、最初に確認した私の認識が違っているのなら、
私の考えを改めないといけないから、>>40 の意味を詳しく教えてほしい

>>51
回転方向は一定じゃないよ。三角で表現すると難しいから四角で表すけどこんな感じ。
　←　→　←
↓　↑　↓　↑
　→　←　→
３個の四角のそれぞれ隣接する辺が逆向きにならないようにしないといけない。
逆向きにすると四角同士が共有する頂点に誤差が発生し、頂点が隣接する部分に穴が開くんだ。
だから、全ての辺のめぐりを同じ方向にすることはできないよ。
これが三角形でも発生するわけ。

頑張って色々テストしてくれるAIつくればいいじゃんwwwwwwwwww

>>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 を読んでそれくらいは自分の環境に合わせて知恵を働かせて読み替えてほしいのだが

>>32
だから、「コーダー＝写経する人」ってどんな人達なのか説明しろって

>>38
どうやってテストするも何も、テストケース毎に引数を与えて戻り値チェックするだけだろ

>>55
> 「写経」というのが、詳細な設計情報をただ単にコードに落とすというのを指してるとすると、
という前提条件の元で進んでたと思ってたんだがな。

は？
>>26
>おそらく君が日常的に接しているソフトの大半はその写経で作られてる。
↓
>>31
>コーダってもうWeb業界でしか使わないよ
↓
>>32
>うん、そういう人たちはPGって呼ばれてるね。

PGと呼ばれてる人の定義は？
コーダの定義は？

>>38
何をやってるのかわからんが、穴が開くかどうかとテストのしづらさにどんな関係があるんだ？

だからさ、写経の元になる
設計がどんなのか言ってみろって。

たとばクイックソートの設計。
その設計を ”写経” すればコードになるんだろう？（・∀・）ﾆﾔﾆﾔ

写経ってのはコードをそのまま写すことを言うんだよ。
書いてあるものを全くそのまま写す。

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

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

コーダーっての設計でできたコードを紙に印刷して、
はそのコードをコンピュータにそのまま入力するのが仕事。

>>58
> PGと呼ばれてる人の定義は？
> コーダの定義は？
遠い昔の話しさ。
昔はコンピュータがものすごく高価で
一人一台無いの当たり前、数時間単位で交代で使っていた。

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

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

今は、コードを紙に書くなんてことはしないので、コーダーというのは存在しなくなった。
もしコーダーがいる会社があったとしたら、そこのプログラマは手書きでもしてるのか？って
言いたくなっちゃうよ。

>>54
>辺を共有するハーフエッジが互いに同方向を向くかどうかを調べればよくないか？
その値を出すことは可能なのは解るよ。じゃあそれをどうやってコードに落として自動テストするの？
そこが問題だよ。もうひとつ聞くと、それは式が正しいかであって結果が正しいかは調べられないよね。

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

左上の三角が辺のめぐり順が正しい場合。
右下の三角が辺のめぐり順が間違ってる場合。
右下の方は解りやすいように、分解度を下げ、
穴が開いた周辺の三角に色を塗っておいたよ。

>>63
三角形を描画する関数をスタブに置き換えて、三つの頂点を a, b, c として、
・描画済みの辺の集合に ab, bc, ca を追加
・描画済みの辺の集合に ba, cb, ac があればエラー
とするだけでしょ。全然テストしやすい部類に入ると思うけど。

なるほどね。じゃ式が正しいかじゃなくて描画結果が正しいことはどうやってテストするの。

>>63
・前者について

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

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

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

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

で君は「細分化後の三角形リストからハーフエッジを表現する有向グラフを作る方法」
結局のところこれが分からないから教えてほしいと言うことなのか？

・後者について

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

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

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

つまり、レンダリングを計算する式の正しさを検証するテストについて考慮していない

>>67
>つまり、レンダリングを計算する式の正しさを検証するテストについて考慮していない
その通りだね。あくまでもレンダリング部分は正しいという前提で書いてるよ。

>「レンダリングされた結果」だけを結びつけて
>「式が正しいかであって結果が正しいかは調べられない」と言っているように聞こえる
これもその通り。そもそも>>43さんとの間に式というものに認識の齟齬があるのかも知れない。
今のところ、こちらとしては>>43さんのいう式は回転の向きの計算だと思ってます。
じゃSubdivision関数全体のテストをするにはどうするの？ってのが気になってます。
で、今のところSubdivisionのテスト結果は描画結果が正しいかで判断するしか
無いだろう、別の方法でもあるのかなーという風に思ってます。

レンダリング部分に問題がない、かつ、面の向きも無関係ならば
あとは細分化した三角形の頂点座標が同じかどうかチェックすれば十分では？

>>68
結局のところ、何をテストしたいのかはっきりさせればいいのでは。
Subdivision関数を呼び出したときの描画内容をテストしたいのなら、
描画結果の確認をするだろうし、
Subdivision関数自体の動作をテストしたいのなら、描画APIを自前の
ものに入れ替えて、APIに渡される座標値などをチェックするだろうし。

>>68
> じゃSubdivision関数全体のテストをするにはどうするの？ってのが気になってます。

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

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

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

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

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


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

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

しかし私は、正しい方向で巡っているかどうかすらテストできていない状態で、
Subdivision関数全体とやらが正しくテストできるとは到底思えない

>>62
だから、今でもコーダーという職種が存在してるってば
Web業界に

レンダリングの結果が正しいかどうかというのはレンダラー側のテストであって、Subdivision()とは関わりが無い。
Subdivision()が正しく動作しているかどうかの確認項目に、レンダラーに正しく情報を渡しているかどうかが
あるなら、それをチェックできるようにすべき。

上記のSubdivision()が何をしているのかわからないが、「座標を計算し、描画し、何らかの結果をboolで戻す」
関数だとしたら、それは責務が多すぎるのでリファクタリングしてテストしろと思う。

「小さい穴が開く」かどうかが問題だとわかってるなら、なんでそれを検知する仕組みを入れて
てすとしないんだろ

呼び出すととprivateなメンバに計算結果を保存するメソッドがあって、その計算結果が
privateなんで正しいかどうかチェックできんわーと言ってるのと同じだな。

観測が必須なのに観測できないコードだからテストできないのなら、観測できるような
設計にしてからテストすればOK。なんも難しいことなんて無い。

>>70
そうですね。
テスト目的自体は、Subdivision関数が正しい結果をだすか否かを確認し、
この条件での実行は問題ないと証明することです。
別に何が原因でバグが発生したかはどうでもいいといえば、どうでもいいです。

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

>>71
>>74
私が穴が開くって所を引きずったせいで、ややこしくさせてる感じがありますが。
穴が開くのは、「穴が開いたり」と書いたように、飽くまでコーディングミスで起こり得るバグの一例です。
他にもコーディングミスで三角形全体を囲む辺がでこぼこになったりというのもあります。
ただ、あくまでテストなので、正しいか正しくないか2択の結果が得られれば十分だと考えてます。

>>76
Subdivisionはとりあえず置いといて、
使ってる描画APIは頂点を共有する三角形を複数描画した時に
(うまく頂点を指定しないと)穴が開いたり、
辺がでこぼこになったりするものなのか？

上記の問いに対する答えがYesで、かつ正常に描画されることを確認したいのなら、
描画結果を保存して、理想的な描画結果と比べるしかないだろう。

>>77
塗りつぶしの処理自体は全く問題有りません。
自分が作った塗りつぶし処理を使う必要もありませんから、
出来合いのライブラリつかってもいいですし。

>描画結果を保存して、理想的な描画結果と比べるしかないだろう。
見比べるんじゃなくGood, Bad、 成否といった形で結果が欲しいんですが。
このスレの趣旨はテストの自動化だと思って今まで質問してきたつもりです。
全てのテスト条件の結果を一枚一枚見比べるというのは昔ながらの方法じゃないですか？

比べるのも自動化したらいいよ。

出来合いのライブラリ使えば、穴も開かなくて済むんじゃないの？

>>78
本来、描画する方法が正しければ、>>79 の言うように
画像比較「でも」正しく、かつ自動的に Good, Bad でテストできる
その方法を初めに >>43 で言ったはずだ

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

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

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


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


私からは２つのテスト方法、画像比較とハーフエッジをの提案したが、
それで不満であれば私が提案できるテスト方法はもうない
（２つの方法の処理速度改良案、あるいは計算機科学的に正しさを証明する方法はあるが）

>>81
紛らわしいタイポをしてしまったので訂正する

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

このどちらか「しか」ありえないと私は思う

>>81
>１ピクセルずつ元画像と比較すれば良いだけだ（プログラム的には至極簡単）
ここに関しては異論はありませんよ。これしか方法が無いのかとも思いますが。

>>83
> これしか方法が無いのかとも思いますが

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

まさか、画像比較ではない >>66 の方法は無視するという意味ではないよな？

そういやprivateメソッドの話で思い出したんだけど、
なんで、オブジェクトに自己内部テストを行う
publicなselftestメソッドを作ろうって話にならないの？

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

オブジェクト自身にprivateなメソッドのテストを行う
selftestメソッドを持たせてもいいと思うんだけど。
つまりオブジェクトには（自分自信の）テストコードが含まれてる。

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

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

２行目と３行のテストは何が正しいことを確認するテストを意味しているのでしょうか

>>86
関数を作る時、その関数になったら、小さい関数に分ける。
この時小さい関数は外部から呼ばれることはない。
（作った理由が長いだけだから）

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

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

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

これでいいかい？

× 関数を作る時、その関数になったら、小さい関数に分ける。
○ 関数を作る時、その関数が長くなったら、小さい関数に分ける。

実際にハードウェアでは
自己チェックモードを備えているものがあるよね。

インターフェースのチェックではなく
自分自身が壊れていないかチェックする機能

>>87
つまり、内部でしか使わない関数の正しさをテストするために、
その様な関数をコールして値と結果の整合性をテストする処理が書かれた
publicなselftest関数を作れば、外部からそのselftest関数をコールしてテストできる
という意味でしょうか

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

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

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

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


なので、publicなselftestメソッドを作ろうって話になる（盛り上がる）には、
今ひとつ方法論としてのインパクトに欠けるような気がします

> クラスのプライベートメンバへ外部からアクセスする手段が用意されているので、
これがいかんのよ。

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

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

で、なんでselftest関数なのかというと、
個々でばらばらで作るんじゃなくてselftestで統一されてれば
コードを書かずともあとはフレームワークやら何やらが
見つけて勝手にテストしてくれるようになるでしょ？

>>83
> これしか方法が無いのかとも思いますが。
だって、レンダリングがおかしくなる条件がはっきりしてないんだからしかたない。

これが「xxという条件のときに、レンダリング結果がおかしくなる」とわかっていれば
xxという条件が発生していないかどうかでチェックできるんだけど、一連の書き込み
からは、どうもその条件がはっきりしない(というか、はっきりさせたくない?)わけで。

>>85
拘束条件(不変表明)が守られているかどうかをチェックするためのI/Fを作って、
呼んでもらうようなことはよくやる。

どちらかというと、テストのためというより異常状態になったときに検知するための
Assertに近い使い方だけど。

>>91
プライベートがあくまでプライベートと言うなら
publicなselftest関数はあくまでパブリックじゃないの？
「これはselftest関数だから
テストフレームワーク以外から呼ばないでね てへぺろ」
とかドキュメントにでも書いとけば許されるのか？

>>91
それって、selftest関数自体は外部からテストするような格好でコールされるんですよね

単にselftestという名前を統一的に決めておいて、
テストツールから自動的にこの関数がテスト目的で呼ばれるようにするだけのこと？

>>95
”誰が”テストをするかを明確にするためのもの。

コードを有るべき場所に置く。
自分のことは自分にしかわからない。
そこがあるべき場所。

”誰が”テストコードを書くかを明確にするためのもの。

>>96
selftest関数の意義はわかりましたが、
仕組みや、できる事できない事がまだ今一よく分りません

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

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

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

他にも、こういうタイプの関数はselftest関数では難しいとか、
こういうタイプの関数ならselftest関数でテストする利点があるとか、
何かあるでしょうか

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

このスレ的には、そこはどうでもいいってことにいい加減気づいてください。

>>38のコードが糞過ぎて、ほんとイライラするんだが、

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

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

何で穴が開くだの、描画結果がだのという話が出てくるんだ。

>>100
その話はもう終わってる

>>98
モックやスタブについて調べろ
君の使ってるプログラム言語で使いやすいものが提供されてるかどうかは知らない

なお、当たり前だが、厳密にはプログラムのテストというものは不可能だ
どれだけコストを妥協して実際に近づけるかという話でしかない

>>91
テストは往々にしてテスト用のライブラリ等を必要としたりするが、テストを実行したくない人に
その準備を強要するのはいかがなものか。
Debug buildの時だけ有効にすれば良いと言うかもしれないが、そのようにすると、Debug build
できる環境に制限を与えてしまいよろしくない。
どうしてもテストしたければ、非公開クラスとしてくくりだして（そうできる言語・環境は限られる
かもしれないが）テストすれば良いのではないか。

>>103
3点

魅力が足りない

>>91
> コードを書かずともあとはフレームワークやら何やらが
> 見つけて勝手にテストしてくれるようになるでしょ？

テスト用フレームワーク使ったことないでしょ。
単に実行してくれるだけじゃ駄目なの。

>>100
本題と関係ないんで説明しませんでしたが
戻り値は描画処理から返ってくるクリップ範囲の判定結果ですよ
テスト用じゃありません

>>106
なんで細分化関係の処理と描画関係の処理が仲良く合体してんだよ
さっさと別れさせろよ

>>107
なんでだよ
あと、どうやって

>>107
このSubdivisionは描画関係の処理なんですが。
細分化した三角形の描画中、クリップ領域の外に出たか
内側に居るか判定できないと非常に効率や取り扱いが悪いです。
まさか、細分化した座標をコレクションにでも保持しておけというのですか？

>>109
ふつう細分化（Subdivision）ってのは、トポロジーとジオメトリーの処理

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

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

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

疑似言語で簡単に言えば

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

このように一つの意味の塊毎に関数を独立させ、
別の関数において、それら分けた関数をもう一段抽象度の高い意味で繋げる

>>110
それすると実行効率が非常に悪くなるんですが。

すいません。さっきの話はどうでもいいので、引き下げます。

>>106
テスト用じゃないって、意味がわからないんだが。
戻り値をチェックしなくて、何をチェックするんだ？

そもそも>>38のコードに、描画に相当するコードが見当たらないんだが、一体どの部分を言ってるんだろう。

>>113
> 戻り値をチェックしなくて、何をチェックするんだ？
仕様通りに副作用が発生するかをチェックすることは普通にあるけど。

>>115
そんな話はしてない。
戻り値がテスト用じゃないとかほざいてるので、それに返信したまで。

>>115
俺（>>107 >>110）も
奴が「戻り値は描画処理から返ってくるクリップ範囲の判定結果」と言ったから、
元のコードを見ないままレスした

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

奴の発言を 100% 信じる
違ってたら奴が全て責任とるだろ

>>109
> 細分化した三角形の描画中、クリップ領域の外に出たか
> 内側に居るか判定できないと非常に効率や取り扱いが悪いです。

もはや何を聞きたいのかわからん状態だが、何で描画「結果」が必要なんだ。
描画「結果」なんか不要。rendererはstubかmockにしろ。
で、rendererに渡った引数で「リップ領域の外に出たか内側に居るか判定」できるだろ。

>>Subdivisionの人

このスレは、「テストしにくいコードをテストする方法」なんだから、テストしにくい点があるなら具体的に書け。
今までの書き込みでは、テストしにくい点なんか見当たらないんだが。

>>109
なんでメソッドを分割しないの？
宗教的制約？

設計が悪い。

はい、次。

>>116
戻り値は、再帰の枝刈り用じゃないの？

>>38のコードの話題する人、名前なりTripなりつけてくれないかな

そもそも"/ 2"とかしていいんかとか言ってみる

テストと関係無い話はよそでやってくれないかなぁ

>>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の方の方法で大体結論が出てるのかなと思いますが。
ただ、ハーフエッジに関しては、テストできる範囲がめぐり順だけでテストの要件にあわないのと、
画像の比較チェックをしてしまえば不要になりそうなので、効果が懐疑的ですが。

>>126
> テストの要件にあわない

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

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


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

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

質問文をどう読んでも、「正しい方向で巡っているかどうか」
をテストしたがっているようにしか読み取れないんだが
私の読解力が不足しているのだろうか

>>127
何度も書いてますが結果を保証することが要件です。

今更ですが、関数の名前が糞なのは認めます。
本来であればGradientShellとでもすべき名前です。

たとえばSum(int a, int b)のテストコード書くときに
MinValueからMaxValueまで総当たりしたいってこと？

>>128
ハーフエッジではどのような結果が保証できない？

>>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] ) )
　　);
ここでしてるんですが(テンソルに正規化するためにオレオレ関数が多くてすいません)
・分割した際の中点位置が誤っていないこと
・生成した中間色がおかしくなっていないこと
・計算に有限桁数にともなう大きな誤差が発生していないこと

他にも、このコード上では起こりえないですが、
もしコーディングミスが有った場合に備え
特定条件で異常終了しないとか基本的な事柄も色々ありますね。

テストって「与えたケースに対して想定した動作を返すか」
＝あとでリファクタしたときに動作が変わってないか
を検証するものであって

アルゴリズムが正しいかどうかをテストするのは
「テストコード」のテストとは言わないんじゃないの

>>132
> ・分割した際の中点位置が誤っていないこと
> ・生成した中間色がおかしくなっていないこと
> ・計算に有限桁数にともなう大きな誤差が発生していないこと

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

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

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


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

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

>>134
誤解を招きそうだな

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

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

証明したいのではなく、あくまでテストしたのなら、すまんかった
>>134 の後半と >>135 は無視してくれ

>>134
>> ・分割した際の中点位置が誤っていないこと
>> ・生成した中間色がおかしくなっていないこと
>> ・計算に有限桁数にともなう大きな誤差が発生していないこと

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

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

ダメだ、ギブアップ

俺にはもう無理
わけが分らん

>>134

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

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

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

ようするに、ある条件を指定したとき、想定結果どおりの結果がでるか調べる事です。

ＴＤＤ知ってるよね
君以外はこのスレでのテストってＴＤＤのテストのことだと思ってるよ

Sum(1, 2)に3が帰ってくることを保証するのがテスト
数学的に1+2=3と証明することじゃない

>>139
>>43に言ってんの？

>>139
ＴＤＤ以外のテストもありますが？

>>139
私の方の話であれば、
Subdivision( 出力先条件, 座標条件, 色条件 ) → 結果 == 想定結果(画像等)
というテストをしたいので別に矛盾はしてないと思いますが。

で、面倒というだけで技術的課題は何も無いように思うが？

>>142
テストした条件において、想定結果となる
ということしか示せない。条件が少しでも異なった場合になにが起こっても泣かないこと。

で、穴が開くとか辺がずれるって話はどうなったんだ？

証明の話が出てるけど
VDMとかBとかZとかのスレって無いの？

無い

>>17
GUIのテストだけども

質問者が必要な情報をきちんと出さないから、回答者は仮定に対しての答えしか出せず、結果質問者の求める答えが得られないんじゃないか？

必要な情報をきちんと出せるのなら、
ほとんどの場合その時点で質問の90%は自己解決する

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

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

何が必要な情報なのか、そもそも何が知りたいのか、
自分でも頭の整理が全くできていない様子
なんか色々なものをまとめて一発でテストできる方法無いかなと
大雑把に希望を抱いているだけにしか見えない
個々のテスト項目を細かく把握する能力が無い

>>142
だから、なんでレンダリング結果がないと判定できないんだよ？

なんでテストがやりづらいと思ってるのか、きちんと文章で表現しろよ。
だんだんうざくなってるよ、君。

>>142
レンダラーをスタブに置き換えて、レンダラーへの引数を評価するやり方で駄目な理由は？

まだ続けてたんですね。もう>>43さんの話で終わったと思ってったんですが。

>>153
既にそれでも構わないと書いてますよ。

>>155
なんでまだだらだら続けてんの？

>>156
最初の質問者に対してひとりでも反論や質問があれば、そりゃ応え続けるだろ

対応し続けなければ無責任だ

>>157
なぜテストしにくいと思ってるのかを明らかにせずに、なんでこのスレに居続けるのってこと

>>158

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

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

馬鹿な質問しなければ、きっと消えてただろう

テストしにくい訳じゃないけど
処理に時間がかかるテストの扱いってどうしてる？

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

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

で、時間かけてテストさせておいて、その間他のことをしてる

じゃあ次のうるう年まで待つか・・・

>>162
どういう意味なのか、よく分らないのだが・・・

ギャグ？　それとも何かの皮肉？

>>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ツールにやらせてる。
失敗したらメールが来る。

>>163
ギャグであり皮肉

>>161
とかいう思考停止する奴は、プログラマに向いてないと思うよ。

>>161
馬鹿じゃ無いの？
他のことなんかしないで、その糞テストコードをまずなんとかしろよ。

>>166
項目は少ないに越したことはないだろ

>>168
何の話してるの？

>>167
ある計算（処理）が正しいことをテストする場合、
明らかに正しいと信じられる方法を用いて計算（処理）する別のものを用意し、
両者の結果を比較するという方法がある

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

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

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

あなたの言う「糞テストコード」というのは処理時間的に糞だと言うことなのだろう
しかしその代わり、計算（処理）の結果については完全に正しいことが
誰の目にも明らかなコードではある（明らかで無ければテスト結果が信じられない）
そのぶん処理時間がかかるのは致し方がないことだと私は思う

>>160
テスト=正しい答との比較、で済むような単純なアプリでは自動実行で放置。
テスト=設計の間違い探し、が必要な探索的開発では仕様のテストにバックポート。

>>170
何で「明らかに正しいと信じられる方法を用いて計算（処理）する別のもの」を毎回実行するんだ？
一回実行して結果を保存して、それと実行結果を比較しろよ。

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

> そのぶん処理時間がかかるのは致し方がないことだと私は思う
という思考停止ぶりも糞だな。

>>172
結果を保存してと言うが、入力するデータが変わったらどうなる？

以降、なんやかやで自分は正しい合戦が始まる気がするが、>>164でFAでしょ。
スローテストは無いにこしたことはない。

あと、詳細を明らかにせず「うちではスローテストを解消できないのは○○だからだ」的な
話はやめてね。>>170

>>173
テストの基本がわかってないなぁ。
基本的に、入力が一緒なら出力も一緒になるようにコード書くの。
実行時に毎回値が変わるリソースはスタブにするとか。

だから100通りの入力データがあれば、100通りの実行結果を保存しておいて、
あとは何度テストしてもテスト対象の実行だけでいいでしょ。

>>161
> 工夫してテスト時間を短縮させるような
> テストコード案を時間をかけて考えることはしないな

MockやStubとかを使ったことないの？

ケースバイケースでどっちも正しいんだろうけど

このスレ的には>>164的考えの人が多いのかな？
俺の用途だと>>170のほうがしっくりくることが多い
もちろんどっち側も書いてはいる

要素が多いとかで時間がかかるなら、そんなのは1時間に1回くらい自動で回せばいい
普段はモックなりスタブなりである程度の値を渡すテストで代用

>>174
もっともだ、申し訳なかった

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

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

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

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

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

というタイプのテストの場合には、元々時間がかかる処理のテストは、
どうしても更に時間がかかることは考慮しておかなければならないと思う

糞が糞みたいなコード書くと糞みたいな動作しかしない

と糞が自己紹介しております

>>179
ランダムテストしかしないところもあるんだな…

ところっていうかテスト対象の特性によるだろ
それともランダムテスト以上に
有効かつ汎用的な手法でもあるのか？

>>183
ああ、すまん。
うちのところは全件やるのが当たり前だから。

>>182
ランダムテストしかしないわけではない

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

ランダムじゃ無ければ、それこそ >>175 の言うようにすれば良いわけだし

>>185
>>1に書かれてるように、このスレは主に「ユニットテストみたいなもの」に関するスレ。
ランダムに入力値を与え、繰り返してストするのはユニットテストの範疇ではないのでスレ違い。

> そうすると、結局のところテストの度にランダムなデータを使わざるをえない
と思い込んでるだけだな、多分。

>>186
なんで範疇じゃなくなるのかと小一時間

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

>>164のリンク先読んだ？
巷で言われているスローテストとは、何がスローなのかがわかる。

>>187
ランダムテストというのは、アドホックテストやモンキーテストと同類の、ブラックボックステストの手法。
この手法でしかユニットテストができないというのであれば、それは設計が悪い。

一連の発言は>>161の人？

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

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

これは逆で、よほどのことが無い限りスローテストを放置することはしない、というスタンスが好ましい。

>>189
>>179 は「テストデータを境界値、境界付近、中央付近などで毎回ランダムに生成し」って
書いてるから、どっちかって言うとユニットテストを抜粋しているイメージで書いてるんじゃね？

まあ、本当のところは >>179 に聞かないとわからんけど。

なぜ毎回ランダムに生成するのかわからん。
境界値、境界付近、中央付近の値をすべてテストすればいいのではないか。

>>186
申し訳ない
完全に >>1 が頭から抜けていた

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

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

全てのレスに個別に返答できないので申し訳ないが、
私の考え方が間違っているっぽいので、反論はしっかり受け止めたい

>>192
完全に同意。
ユニットテストでは、同値分割するとか、直交表を使ってケースを減らすとかして、「有限・少数の決められた(複数の)値」で
期待した結果が出るのを確認すれば十分。

>>193
最後みたいだから言うが、句読点ちゃんと打て馬鹿。

1、2行ならともかく、がっつり長文書く時でも句読点打たない奴結構見るが、流行ってたりするのか？

句点打たない奴が多いのは、携帯メール常用で、句点打つ習慣が無い奴が増えたからではないかと推察。

ユニットテストは、
・誰もが
・短時間で
・繰り返し
実行できるものをめざすのが良いという認識が共有されてないな。

なんか変な流れだな
ユニットテストは結合テストと対になる概念であって
ホワイトボックステストでもブラックボックステストでもいいだろ

そりゃホワイトボックステストができるならその方がいいだろうけどさ
設計が悪いで済ませるのは横着

>>198
見てると前提や概念が人によって違いそうだからそこらへんを決め付けるなら出展付で頼む

>>198
普通はユニットテストは開発者が自分で実行するテストで、ホワイトボックスで行うのが普通。
ごくまれに、「普通の」手法でユニットテストができないこともあるかもしれないが、
そんな特殊な話をしても建設的じゃないよ。

> そりゃホワイトボックステストができるならその方がいいだろうけどさ
> 設計が悪いで済ませるのは横着
ごく普通に起こり得る、ユニットテストの範囲のテストでホワイトボックステストが行えないような例を挙げてみ？
自分が今書いた/これから書くコードをテストするユニットテストで、ホワイトボックスでテストできない例なんか
そうそう無いと思うけど。

>>198
書き忘れたけど、C0カバレッジとかC1カバレッジというのがなんなのか知ってる？
知らなきゃgoogleへgo。

例えば
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年かかる。
だから、ユニットテストではブラックボックスの手法では駄目で、ホワイトボックスでやる。

>>202
ランダムテストに完全性求めるのがそもそも間違ってる
それでランダムテストが駄目だという結論にはならない

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

どうやってa == 1234567 && b == 987654を探してくるかが分からないなら
ホワイトボックステストでこのバグを見つけるのは
ブラックボックステストより困難だと思うがいかが？

>>203
全然理解してないな。
ユニットテストはブラックボックステストではやらずにホワイトボックスでやりましょう、
ランダムテストでも良いとか言ってる人いるけど、>>202のように全然駄目だよ、という説明なのに。

>>203
何の本読んでソフトウェアテストの勉強したのか教えてくれる？

ホワイトボックステストがどんなテストなのか知らないと見た

ほんと変な流れだよ。

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

的な流れが建設的な会話だと思うんだが。

言っとくけど「ランダムテストでもいい」じゃなくて
ブラックボックステストじゃないと事実上対応できないケースもある
そのケースは言うほど「特殊な話」ではないと思っている（これは個人的感想）
だから
ブラックボックステストはユニットテストに適用できない、すべきでない
という論調はおかしいと言いたい

じゃあ素直な気持ちで

double型(IEEE 754)の2つの数値の掛け算をする関数
double mul(double a, double b)
{
return a*b;
}
をテストする場合どんなテストケースを与えるか？
コードに分岐がないから条件網羅も命令網羅も簡単だがどうだろうか

くどくてすまんが
仕様が不明確とか不十分とかそいういう感想も込みで考えて

>>209
ホワイトボックステストでできるコードの話題はどうでもいい。
ブラックボックステストじゃないと事実上対応できないケースの話をしてよ。

それと、>>205の回答もよろしく。
テストド素人の相手をしても時間の無駄だし。

何だろう。
言語仕様とか、アセンブリレベルの精度か何かをテストしたいとかいうことなのかな。

>>209
えっと、それのどこがホワイトテストでテストしづらいの？

>>209は純粋にみんながどういうことを考えるかが知りたいだけで
自分の主張の正当性だとかを示すつもりじゃないのであしからず
答えたくなければスルーしてくださいな

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

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

スレチだというならa*bをもっと複雑な関数に書き換えるけど
聞きたいことは同じ

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

これのどこがランダムな値のテストなの？
決められた値を引数にして、戻り値をチェックするホワイトぼっくつてすとでしょ。

>> 212
本はむか〜し情報処理試験のときに参考書読んだくらい
あとは*unitとかのドキュメントとかネット情報くらい
テストド素人なので無理して相手しなくても

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

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

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

>>216
自分が長文書いてるのはすまんと思うが
ちょっとは過去のレスも読んでくれよ

>>217
> 分かりやすい例なら任意の大きさの行列の演算とか
> （ホワイトボックステストできないとは言ってないよ）

だーかーらー、なんでこれがホワイトボックステストでテストできないんだよ？

>>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 ) );

>>217
え、テストド素人な上にお前以外が一体何を言わんとしてるのかも理解できないのに、
>>198みたいな断言しちゃったわけ？

>>219
それはやりすぎ

>>221
境界値テストぐらい普通じゃね？

>>218
単純に組み合わせ爆発とか充足可能性問題という観点で

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

>>219
平方根を使うという発想は素直に面白い
DBL_MINの方に一抹の不安を覚えるが

>>223
そもそも、テストケースが先にあって、関数をそれに合わせなきゃいけない。
DBL_MINでこけるなら、関数の方を直さなきゃいけない。

>>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);
}
みたいなテスト（だと俺は理解した）。

>>170
>ある計算（処理）が正しいことをテストする場合
これ以外のテストって何よ？
耐久テスト？
耐久テストでも、指定の負荷までは正しく処理できるって
テストだから、正しいことをテストする事には変わりないよな。

>>225
想定ケースを(数学上の)関数をなぞる様に定点的に作れば、
ある程度、テストとしての信頼度を保てる。
もし、完全なテストをしたいなら、全ての入力値と、全ての想定結果を並べればいい。
なに、-INT_MAX 〜 INT_MAX　になる引数全ての組み合わせをテストするだけだろ、
1日テスト走らせとけば終わる。もし本当にやるとしても、関数デバッグの最後でやりゃいい。

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

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

あと分かりやすい表現として組み合わせ爆発という言葉を使ったけど
線形時間で解けるとしても
1日とか一か月とかそれ以上ってなるような場合も含めて考えている

・ブラックボックステスト　・・・　使用を満たしているかの検査
・ホワイトボックステスト　・・・　想定どおりの処理フローを通っているかの検査

ホワイトボックスなんてassert貼っときゃいいんだろ

>>227
> なに、-INT_MAX 〜 INT_MAX　になる引数全ての組み合わせをテストするだけだろ、
> 1日テスト走らせとけば終わる。もし本当にやるとしても、関数デバッグの最後でやりゃいい。

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

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

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

つか、体系的なテスト手法を勉強したことがないんだろ？
何冊か本を買って勉強しなよ。

>>228
> だがやっぱり（ゼロとかNaNは自分でも判断に迷うが）
> ブラックボックステストだと理解しているんだが

"black box test is"
でググれ馬鹿。

いいかげん、テストしにくいコードの話をしようぜ。

>>197までは全然変な流れじゃ無かったのに、>>198から流れが変になったｗ

>>222
ライブラリを第三者がブラックボックステストする場合なら普通。

100回試行するのか1000回試行するのかわからないけど、ランダムな値を使ったテストが有効で、
なおかつその実行時間が0.1秒未満なら（できるなら10ms未満）、ユニットテストでやってもいいかな。

ただ、本当に有効な場合にのみ実行すべきで、「いつでもランダムテストを追加すればテストの
信頼性が増す」という思考停止は良くない。

0.1秒未満というのは厳しいと思うかもしれないが、ランダムテストが100個増えればテスト実行時間が
10秒増え、頻繁なテストスィートの実行のやる気をそぐ。
個人的には、100個のテストが1秒未満じゃ無いと嫌だ。

試行回数が多いのが遅くなる原因で
ランダムであるかはあまり関係ないということを
念のためお忘れなく

やる気まで含めると費用対効果の評価は個人差が出るので
試行回数の決定はなかなか難しい
そもそもテストの実行回数が人によってだいぶ違う

何回もって、デバッグ中は境界値テストだけでいいだろ。
時間の掛かるテストはほぼ問題ないという最終段階ですりゃいいだけ。
せいぜい3回が限度。4回も5回も時間の掛かるテストしなきゃならんほどミスするやつは
プログラマーやめりゃいい。

今も有るのか知らんけど、情報処理試験に出てきた「バグ埋め込み法」ってなんやねん。
ググっても試験問題しか出てこんぞ

>>240
問題読まんと何ともきいえん

>>240
> ググっても試験問題しか出てこんぞ

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

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

この説明読んでもわからないと言うなら、プログラム関係の仕事に付かない方がいいと思う。

>>242の読解力のなさの方が
プログラム以前に社会人として致命的に思えるが

>>243
マジでどうおかしいか指摘してくれ。
どうみても、「バグ埋込み法」について聞いているとしか、読解できなかったんだが。

>>243
書いた本人乙
>>240の文章力が稚拙すぎるだけ

>>242
どういう方法かを聞いてんじゃないんだよ
試験問題上以外で実在してんのかっつうこと聞いてんだよ

>>244
お前が持ってきたページも試験問題だろうが
>>240は試験問題しか出てこないと言ってる時点で内容は知っていて
すくなくとも内容のことを言いたい理由じゃないことぐらい解るだろ

>>246>>247
日本語の勉強やりなおした方がいいな

表現力が拙いのに偉そうにオレはこう言ったんだよ！ 君に答えると
現実にあるよ。その名で皆が皆呼ぶかまでは知らんが

ヤベぇ本格的なコミュ障がいる

なんやねん
みたいなど田舎の方言つかうから悪い

>>249
>現実にあるよ。
具体的に。

>>240の文は稚拙というよりあいまいさだな。
>>242もそのあいまいさを無視して断定的な解釈をした。

曖昧な表現/きめつけ
どちらもバグの温床

>>249
> 現実にあるよ。

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

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

それなりにきちんと運用できてるなら、凄いと思う。

>>252
前の現場とか、前の前の前の現場とか

>>254
試験問題以外で、具体的に手法を記述、または紹介した資料はないのか。

>>254
そこまで精密な数値とかは期待してない

最低限これらが拾われないようじゃ、テストがザルだから不味いよね？判定に使う位かな

うっかりバグを混入させた時の言い訳に使えるな！

>>257
「精密な」数値以前に定性的な判断しかして無いな

>>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.

>>253
>>>240の文は稚拙というよりあいまいさだな。

あいまい？

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

以外の解釈プリーズ

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

>>257
なるほどね。
そうは言っても、開発者以外にコードがそれなりに理解できる人 (でないと埋め込めないよね？) が、
ちゃんといる組織かぁ、ちょっと羨ましいな。

>>259
テストチーム自体の品質がわからんから、大雑把にでも把握しとけば後々色々と捗る

>>261は話しかけるとめんどくさそうなのでスルーで

>>261
いや、開発者(つーか俺)がバグを埋め込むんだよ
それらのバグが全部発見されれば、QAチーム(テストチーム)は最低限の及第点はクリアしてる
安心して任せられる
一つも発見されないとしたら、マネジメントに働きかける必要があるサイン

人を試すようなやり方は
うまく振る舞わないと軋轢を生みそうだな
まぁ既にあるからいいって場合もあるか？

>>264
ああなるほど、QA 自体のテストね。
でもそれってテスト期間長くならない？
見つけても、見つけられなくても、埋め込んだバグはつぶして再度テストしないと
いけないと思うんだが…

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

>>263
うん、君にはちょっと難しい話だから、スルーしててね。(w

>>265>>266
軋轢は指摘通り。
トップダウンで、わざと埋め込んだから見つけてね！みたくやっとかないと危ない。
それか、意図的なバグでも自分のミスってことにしとくか。
権限大きいロールなら前者、権限少なければ後者。
後者をやる必要があると感じるのは、例えば、新人をテスト要員に充ててるよーなプロジェクト。

あと、テスト期間への悪影響はないと思ってる。
というのも、一定期間にテストで見つけられたバグを→全部潰して→またテストして貰う
っていうバッチちっくなテストプロセスだったから。
全く違うテストプロセスなら長くなるケースもあるかもしれんけど。

>>267-268
なるほど、とてもうちでは採用できないけど、そういうことやってるところもあるんだと
参考になった。ありがとう。

以上、自演を終わります

>>256
capture-recaptureでググれ

キーワードは
software testring capture-recapture
の方が良かった。

256じゃないが�d

Bebugging
Fault seeding
Fault injection
Mutation testing

とか色々呼び方あるのな

>>238
テストの実行回数については、スローテストが無く、今やってるクラスや関連クラスのテスト全部を
実行しても数秒で終わるなら、ファイルのセーブ単位やコミット前にテストを実行する気になる。
その結果、頻繁にテストが行われるようになり、どこかが壊れれば早い段階でわかるようになる。

ユニットテスト、に対する認識の違いが、人により思いの外大きいというのがここまで読んだ感想。

まずTDDやBDDを導入しているか否かで全然違うな

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

TDDやBDDでも実装に入ってからは
実装に応じてテストも柔軟に変えていくべきだと思うが
基本はブラックボックステストだ

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

そんなこといってる奴いるか？仮想的じゃないの？

TDDやBDDを能動的に否定している奴はいないな
思想的に相性が悪そうな奴はいそうだな

このスレの話なのか、お前の周りの話なのかはっきりしてくれ

TDD、BDD否定派ならわかるが、ブラックボックステスト否定派なんかいるのか？

>>280
いることにしないと（または、いないことにしないと）話ができない人ならいる

>>204あたりの字面だけ捉えると
ブラックボックステストは駄目だよ！ランダムテストは論外だよ！
と言っているように読める
これらが>>198の自演ならブラックボックステスト否定派は幻想

その話は、ユニットテストをブラックボックス的手法だけで行うと、>>202のようなバグは検出できないよねってことであって、
TDD/BDDを否定してるとは思えないが。
自分が書いた実コードがそこにあるんだから、ホワイトボックスでテストしましょうぐらいの話でしょ。

というか、TDD/BDD否定派と遊びたいならTDDスレ行きなよ。そこにはいるから。
今は死にスレと化してるが。

つか、なんでランダムテストにこだわってんだよ。
TDD/BDD派ならなおさらランダムテストなんかしようとは思わないだろ。

TDDはともかくBDDはユニットテストじゃ無いしー的な

QuickCheckとは何だったのか

ちょっと古いけど
ttp://madscientist.jp/~ikegami/diary/20060906.html
> プログラマが思い付くテストインスタンスはテストに合格するに「決まっている」。
ランダムテストの是非は別としてこの指摘は言いえて妙だな
感心しちゃいけないんだが

TDDは開発手法であって、テストでもないし品質を担保するものでもありません。

>>275に戻る

>>287
プログラマが思い付くテストインスタンスはテストに合格するに「決まっている」。
↓
合格するに決まってるなら、実行しなくてもいいよね。
↓
実行しなくてもいいならテストコードなんか書かなくていいよね。
↓
テストなんかしない。

> 実行しなくてもいいならテストコードなんか書かなくていいよね。
テストコードが仕様や実装の挙動を明確化する（かもしれない）
という観点では飛べない翼にも意味はあるさ的な

まあ寝ぼけたこと言ってないで有意義なテストをしろって話だが

うんうん、どんなものもランダムテストでテストすればいいよ

この人達、リファクタリングしないのかな
それとも、テストが無い状態でえいやってやってるのかな

XP厨とかTDD厨とかいろんな言葉ができてきたが、新たに「ランダムテスト厨」をそれらに追加しようぜ

まぁまぁ。
テストしにくいコードに対して、ランダムテストが有効な場面はあると思うよ。
ただ、俺が疑問なのは、
int ret = foo(some_args)
という関数をテストするときに、引数にランダムな値を与えるとして、期待結果はどうやって得るんだ？
上の方で言われてたみたいに、別の手段でそれを取得するのか？

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

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

エラーや例外が発生しないこと（あるいは発生すること）は
戻り値を見なくても確認できる

s/不偏条件/不変条件/
意味的には同じだが検索するときを考えて訂正

やっぱランダムテスト厨は言うことが違うｗ

馬鹿か
当たり前のことを書いたらレスもらえないだろ

>>296
やっぱ納得できんな。
int ret = foo(1, 2, 3, 4, 5);
assert(ret == 15);
の方が優れてると思う（ユニットテストでは）。

テストしにくい、ランダムテストが有効な例を挙げてくれれば納得できると思うんだけど。
ちなみに、<<287のリンク先の例は、全く同意できない。

機械学習のコードをテストしたときは
ランダムにデータを生成して、学習が進むこと（エラーが下がる等）をチェックした
これは一種のランダムテストだろう

>>300
ランダムテストとランダムテスト以外の優劣を比較している時点で
ランダムテスト厨や「ランダムテスト厨」厨と変わらないよ
優劣は個別のケースについて検討すべきこと

そして>>296はランダムテストの評価法じゃなくて
仕様を満足しているかどうかの一般的評価法

ランダムテスト以外とランダムテストの決定的な差は
無限を部分的にでも扱えるかどうかという点

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

繰り返すがこれが長所であるかは個別のケースによる

ランダムテストは、人間が思いもつかないようなバグを発見するのに使える

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

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

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

ユニットテストはあくまで人間が思いつくケースしかテストできない
その方が良い場合もあるし、ランダムテストの方が向いている場合もあるし、
ユニットテストしてから、軽くランダムテストしてみる場合もある

>>304
すまん
実際はアマチュアで個人でプログラムしてるだけで、
テストなんてそうしたことないから適当なこと書いたけど
間違ってないよね？

反応が無いとちょっと心配になってくる

>>304
言いたいことはわかるし
大きく間違ったことは言ってないと思う
しかし>>300の疑問の答えにはなっていないんじゃないかな

>>296
例外もテストの結果だ
いろいろおかしいぞ

>>296は>>295に対するレスってことくらい読み取れよ
いろいろおかしいならおかしい点を建設的に指摘しろよ

>>308

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

例外の発生有無もも期待結果なの。
あたかも、何か他の手法があるかのように前ふりして、
結局中身がないので読むだけ無駄な点で有害ってこと

>>309
勝手に変な期待して期待外れだったからって文句言われても
しかも>>300で「一般的評価法」とまで述べているのに

それはそうと
例えばNUnitのConstraint Modelは
事前条件・事後条件・不変条件が明確になるから
仕様との対応が分かりやすいけど
NUnitユーザはConstraint Model活用してる？
実のところ自分はあまり使ってないんだが

失礼
>>300でなく>>302

なんかスレチだな

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

うーんやっぱスレチだな

仕様：
正の整数nに対しf(n)はn未満の偶数を1つ返すものとする
n, f(n)の値はunsigned intで表現できる範囲の数とする

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

こういう場合にどういうテストを書けばいいか？という感じか

あ、正の整数じゃなくて自然数nに訂正

ゼロを含まない自然数の定義もあるから駄目だな
ゼロまたは正の整数n

で、どこがテストしにくいの？

じゃあ俺は
テストしにくいコードを作る方法を教えてください

>>317
お前がコード書けばいいよ

>>304
ランダムテストの有効性を問うてるわけでは無くて、ユニットテストという文脈でランダムテストが
有効なのかどうかがこのスレの話題。

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

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

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

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

これは、俺の認識ではもはやユニットテストの範疇を超えてる。

適当な事を書いたと言ってる奴にそんなツッコミ入れても・・・

> 仕様：
> 正の整数nに対しf(n)はn未満の偶数を1つ返すものとする
> n, f(n)の値はunsigned intで表現できる範囲の数とする
f(5)の戻り値が何なのかわからんぞ

>1って特定の順序を踏んだ場合に線が正常に書けずドット欠けするからテストしたいってのが本当に聞きたかった事だろ？
それは解決したの？

したでしょ

>>321
f(5)は5未満の偶数を1つ返すんだから0,2,4のいずれかだろ

これは極端な例だが
結果が一意に定まる一般的必然性はないだろ

うわこいつめんどくせぇ

>>324
そういう仕様だとしようか。

で、どこがテストしにくいの？

2や4がどの程度発生するべきかわからんね
return 0
なら仕様をみたすけど、本当にそれでいいの？使い物になるの？っていう
仕様の不透明な感じがイヤな臭いを放ってはいる

わからないことは、テストできませんね。不可能。

はい、次。

仕様が不明確だからテストできないというのは、このスレの対象外の話題です。

仕様が不明確な場合のテスト方法→仕様を明確にする

仕様が不明瞭だとテストのしようがありません

assertInArray([0, 2, 4], f(5));
で十分。

なんか見てると外延的なのが好きみたいね
内包的な記法の方が流行ってんのかと思った

内包的記法は強力すぎてバグの温床というのも
わからないでもないけど

強力すぎる内包的記法って、具体的にはどういうやつ？
なんで強力すぎるとバグの温床になるの？

内包でテストとかもはや何のテストしてるかわからんくなるな

>>313の例なら
内包的(implicit)
assert(isEven(f(5)) && f(5) < 5);　みたいなの

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

内包的な記述の方がテスト対象に何を期待しているかを
分かりやすく「厳密に」記述できる
が、isEven()みたいに名前から実装が想像できる場合はともかく
複雑になってくると何をやっているか分らなくなる可能性はある

>>336
良く考えるんだ。
たとえば、引き数で指定したn個の数をすべて掛け合わせた結果を返す関数
f(x1. x2,…,xN)
を、内包でテスト書いてみ？

>>336
> 分かりやすく「厳密に」記述できる

うーん、
> assert(isEven(f(5)) && f(5) < 5);
より
> assertInArray([0, 2, 4], f(5));
の方がわかり易いし、厳密だと思うんだがなぁ。まぁ「厳密」の定義とかいう話はしたくないんだけど。

複雑だけど実行速度が速いアルゴリズムと
シンプルだけど遅いアルゴリズムがあったとき、
前者を実装したコードのテストに
後者を使う事はあるよ

>>337
良く考えるんだといわれても
assert(x1 * x2 * ... * xN==f(x1. x2,…,xN));
くらいじゃないのかね
それじゃテストにならないという意見を否定するつもりはないが
じゃあ他のテスト方法はあるの？
x1 * x2 * ... * xNをそろばんで計算した方が有意義とでも？

>>338
>>336には「テスト対象に何を期待しているか」と書いてある
assertInArray([0, 2, 4], f(5));
をパスして仕様に反するf()はいくらでも作れる
そういう意味での「厳密」

だからといって内包的なのが良いとか万能というつもりはない
少なくともテストにおいては

形式手法では話が変わる

>>340
テスト対象のメソッドの中身と同じようなテストコードを書くか、
別のロジックを書き出すことになるか、
になってしまい
何のテストを書いているかわからんくなるのがオチだろう

テストはそろばんの方がいい

一般には適用できないが>>337の例なら
・引数のいずれかがゼロのとき結果がゼロになる
・1はいくらかけても1
・log(a*b*...)=log(a)+log(b)+...
とか数学的な性質を使った切り口がいいと思うけどね
内包的に書くにしても外延的に書くとしても
暗算するにしてもそろばんを使うにしても

>>340
ひょっとして、「仕様の記述レベル」の話してる？
だとするなら、テストメソッド名やコメントに入れれば良いんじゃないのと思うけど。

> assertInArray([0, 2, 4], f(5));
> をパスして仕様に反するf()はいくらでも作れる
いくらでも作れたとしても、それは
> assert(isEven(f(5)) && f(5) < 5);
もパスするよね？

何を主張したいのか良くわからないけど、
・バグの温床
・複雑になってくると何をやっているか分らなくなる
メリットどこにもないじゃんｗ

>>333
> 内包的な記法の方が流行ってんのかと思った

というのは、良く目にするということ？
何かの言語界隈とか何かのテストツール界隈では、内包的記法が普通なのかな？

>>344
assert(isEven(f(n)) && f(n) < n);
にすればいいだけ

>>345
ある方法ではできないことがこの方法ではできる
それを必要とするならメリットだろう
必要を感じない人には関係なかろう

両方かいとけばいいんじゃね

>>346
BDDがどのくらい流行っているのか知らないが
仕様とテストコードを近づけるという点では
内包的記法が有効というのは自然な発想だと思う

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

あと流行ってはいないが形式仕様記述では
内包的記法が無いととてもじゃないが使い物にならない
テストの範疇じゃないけど

なんか回答としてぼやけてるな

内包的記法を実際によく見かける訳ではないが
近年のBDDやNUnitのConstraint Modelの登場を見るに
内包的な記法が注目されている気がした
（が別にそんなことはなかったぜ！）

そもそもassertの中であんまり条件分岐して欲しくない

>>347
本気でわからん。
> assert(isEven(f(n)) && f(n) < n);
これ、nに何か値を入れないと動かないよね。
n = 5;
assert(isEven(f(n)) && f(n) < n);
とでもするの？

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

まあ、人それぞれなんだけど。

>>350
そもそも、仕様を記述するときに内包的な記法が有効なのはあたりまえで、

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

なんて仕様だったら、それこそなんだかわからんわ。

あ、ひょっとして、
for i in 1..10000
n = random_number();
assert(isEven(f(n)) && f(n) < n);
next
とかしたいのかな？

たとえば「文字列の中間に'-'１文字挟んで返す」ってときに
内包なんとかで書いていくと
テストコードの方がバグもってるってことが起きるんじゃないの

>>352
> 数学的機能法的な考え方や、〜
が「仕様とテストコードを近づけるという点で」どう役立つのかの方が
俺には分からん

もし数学的機能法が数学的帰納法のことなら
内包的な発想そのものだと思うのだが

内包でかいたら、
その記述にコードと同様のバグが踏襲されたりして
テストにならんだろ

>>348の言うように古典的なテストと並記すればいいんじゃね
使えるところだけ使うという合理性はないのか

>>356
> >>352
> > 数学的機能法的な考え方や、〜
> が「仕様とテストコードを近づけるという点で」どう役立つのかの方が
> 俺には分からん
仕様とテストコードを近づける手法を説明したわけでは無くて、ユニットテストの手法として
有効なのはこっちじゃないのという手法を書いた。

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

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

そうじゃなくて、「厳密なテスト」ができるというなら話は別。

そもそもテストと仕様を記述形式によって近づけよう、近づけたい、という動機がわからない。

お前ら、テストしにくいコードの話しろよ

このスレの会話がテストしにくいコードそのものだよ

まぁソフトウェアテスト総合スレ的なのが無いから、テスト全般について語られるのは仕方が無いともいえる。
テストしにくいコードの話題が無いんだったら、テスト全般の話題でもいいと思うがどうかな。

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

「厳密なテスト」なんてありえないんだからそりゃ欺瞞だよ
実装コード流用してテストコード書く手間を省いてるだけだろ

本当にテストしにくい場合
同様の経験がある人同士のあるあるネタ以上に話題が発展しない
別にテストしにくくない場合
素直に解決策が提示されるとそれ以上話題が発展しない
解決策が提示されないと煽りや揚げ足取りに走り話題が発展しない

要するに話題が発展しない

基本的なこと訊きたいんだが

ゲームを作っていて、全てちゃんとユニットテストから作って、
それにパスするようにプログラムしていたら、
仕様から外れているかどうかを見るタイプのデバッガーは不要になる？

>>367
少しは上の方のレス読んで自分で考えろよ
既に考えてることがあるんなら後出しせずに先に書けよ

デバッガーが必要かどうかは最終的にビジネスの問題で
プログラム云々の話じゃないというのが個人的な感想

>>367
> 仕様から外れているかどうかを見るタイプのデバッガー

最近はそんな便利なデバッガーがあるのか？

>>369
普通にやるだろ。

３つの条件を揃えないとこの扉は開かない、という仕様だったら、
本当に揃えないと開かないのか、別の条件でも開いてしまわないか、
揃えても閉じたままにならないか・・・
デバッガーが開発者の想定外の行動を色々してみて調べる。

ゲーム業界用語を説明なく使っていることに対する皮肉だろ

テストプレイヤーのことをデバッガーというのはどうもね。

>>364
なんとなく文章の解釈とか語義定義とかそんな感じになりそうな気がするが、
そういうのは一切やりたくないので念のため。

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

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

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

言い方を変える。

内包的記述でしか書けない場面に遭遇したら、それは内包的記述で書けば良い。
それは特殊例として、一般的に内包的記述が仕様を明確/厳密に記述できることを越える、
テスト的なメリットがあるかどうかが知りたい。
ランダムテストには、プログラマが想定しなかったバグをあぶり出すこともあるというのがメリット。

>>367
プログラマが真の仕様を正しく理解している保証はどこにもないから、たとえプログラマ自身が
100%のテストをしていたとしても、第三者の検証は必要。
これはゲームに限った話では無い。

>>369
>>370
すれ違いっぷりにわろた

マルチコア対応のコードをテストするイケてる方法を教えて下さい
とりあえずMPI系

どんなコードだよ

便乗ですが、マルチスレッドでクリティカルセクションのロックが適切かどうか、って一般的にはどうテストするのでしょうか？

正規表現ルーチンはどうすれば効率的な
テストができるんだろう

>>379
適切
の中身を書くんだ

>>381
クリティカルセクションを設計段階で見落としてたり、
実装段階でうっかりロックしわすれたりしてる場合に、
きちんと検出するテスト方法が知りたいんす

>>382
前者は無理だな
設計で考慮してないのをテスト出来るわけがない

後者はマルチスレッドで実際に使うコード書いて、状態に矛盾が発生してないかテストすればいい

>>382
> クリティカルセクションを設計段階で見落としてたり、

後からテストコードを書けばいいと思ってるからこうなる

>>382
IBM developerWorks
ConTestを使用したマルチスレッド・ユニットのテスト
並列テストが困難な理由とConTestの活用
http://www.ibm.com/developerworks/jp/java/library/j-contest/

「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）から。

>>386
お買い得なのかベラボーに高いのか全く分らんな

この手のやつの相場っていくらなの？

>>387
テスト対象となるシステムへの入出力を行なうのにかかってた時給×対象テスト時間×対象テスト人員数 ＞ よんしぇんまんえん

なら確実にお得
同じくらいか低いなら個別検討っすなー

>>387
いまいちどういうことをしてくれるのかが良くわからん。

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

ただ気になるのは…

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

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

まあ、この値付けから見て「金融系システム」向けなんだろうから、うちみたいな弱小企業にはあまり
関係なさそう。

副作用はどうやって楽にテストできるか

あげ

テキストボックスから文字を入力して、
所定のラベルに、所定の結果が表示されていること。
これを自動化するにゃどうしたらいい。
こんな感じの検査義読み込んで検査してくれるツールとかあればいいんだけど。
IN:
{
　triggers:
　[
　　{ type:"button", value: "申請" }
　],
　values:
　[
　　{ type:"text", name:"text1", value: "MOX梱包燃料" }
　]
}
OUT:
{
　values:
　[
　　{ type: "label", name: "label1", value: "核取決済状態" }
　]
}

QuickTestProfessional とか TestPartner でスクリプト書けばいいんじゃね？

テストしにくいコードっていうのは、
グローバル変数を多用しているコード

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

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

こんなのはテストしにくい。

>>394
そういうのを副作用というんだよ

>>395
知ってる。

重要なのは、副作用がたくさんあるコードは
テストしにくいって話。

最初からそう言えば良いのに

>>397
それだと一般論で終わるだろ。

ほしゅ

形式言語スレできたよ！
案の定過疎ってるよ！

【Alloy】形式言語による仕様記述【VDM】
http://toro.2ch.net/test/read.cgi/tech/1357387746/

未だに社内でグローバル変数バリバリのCソース書く低能がいて困る

グローバル変数バリバリで書けるんならむしろ頭が良い証拠では？
コミュニケーションスキルが要求される場面で有能かは別だが

テストまで本人が担当するんなら問題なかろう
別にテスト担当がいるならご愁傷様

CPUの稼働率を返す関数とか、時刻を返す関数とかどうやってテストしたらええの

稼働率が0〜100%に入っているかくらいはチェックできるだろ

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

一般的な方法として
別の実装方法があればそれと比較する
利用しているAPI等をデリゲートとかでカプセル化してテスト時はモックに差し替える
とか色々

出力形式がXMLのXSLTのテストってどうやってる？

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

結局XPath式使って評価することになって
Schematronや妥当性を評価するためのXSLTが出来上がるんだけど
あれ？その評価用のXSLTバグってね？みたいな……

>>405
単純なテキスト比較では駄目な理由は？

<x a="A" b="B" />
も
<x b="B" a="A"></x>
も仕様上有効ってこと
単純なテキスト比較だと実装と処理系に依存してしまう
名前空間接頭辞やxlinkや実体参照も加わると更にカオス

ちなみにXML正規化という技術（規格）はあるにはあるんだけどね

diffxmlとかあのへんは？

diffxmlで差分が取れたとして
合否のロジックを記述する手段が必要なんでは？

差分が取れたら失敗でそ

いやいやいや差分の有無で評価できる場合も当然あるけど
一般に使えるわけじゃない

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

いわばXSLTの「テストコード」をどうやってテストするとよいか？
あるいはXSLTのテストコードをテストせずにXSLTの妥当性を評価する妙案はあるか？

テストにはXSLTを使わない

>>407
> 単純なテキスト比較だと実装と処理系に依存してしまう

実装と処理系に依存した期待値とのテキスト比較でなぜいけないの？
というか、テストのやり方間違ってないか？

一体なんのテストがしたいのか、良くわからん。
XSLTに食わせるソースの妥当性？
コードでXSLTを出力していて、そのコードの妥当性？
XSLTを使使った変換ロジックを書いていて、そのコードの妥当性？

>>414
仕様に無い制約は持ち込みたくない趣味
趣味とはいえ非常識だとは思わないんだが具体的にどう間違ってる？
特に今回は身内で閉じたプロジェクトじゃないってのもある

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

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

今の方法はバグを埋め込みやすいし保守性も悪いと感じているので
エレガントな方法やツールがあったら教えてください

　　　　　　　／/
　　　　　／　 /　　　ﾊﾞｶｯ
　　　　 //⌒)∩＿＿∩
　　　　/.|　.| ノ　　　　　ヽ
　　　 /　|　| 　●　　　● | 　　　　
　　　/ 　|　彡　　( _●_)　ミ 馬鹿には無理
　　 /　　|　ヽ　　|∪|　　/＿
　　/／　│　　　ヽノ　　＼／
　　"￣￣￣￣￣￣￣（..ノ

>>416
俺ときみで用語の理解に違いがあるのか、何をテストしたいのか今一よくわからない。
俺が理解するXSLTとはスタイルシートのことで、それをテストするというのがよくわからない。
ひょとして、君が作っているのはXalanのような変換ロジックなのか？
それとも、マニュアルで準備したXSLTが妥当な(要件にマッチした)ものかどうかを確認したいのか？
何れにせよ、決められた入力に対する期待結果がわからないというのがよくわからない。
int sum(int a, int b)は、入力の組み合わせが2^32*2^32あるからテストできないというようなことなのだろうか。Cコンパイラを作ったが、入力されるソースは無限にあるので、出力したオブジェクトの妥当性がチェックできないとかそういうことなのか。

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

何れにせよ、疑似テストコードか具体的なテスト手順を示して、こうだからテストできない/しづらいというのを明らかにしてくれれば、何かアイデアを出せるかもしれない。

訂正。
同値分析じゃなくて、同値分割と境界値分析。
あとやろうとしてるのは、ホワイトボックステスト？ブラックボックステスト？

俺もわからない事が多すぎてもにょる。

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

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

>>412
「一般」とは？

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

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

> 今はその「変換結果の妥当性」を評価するために別のXSLTも使っている
具体的には、どう使ってるの？

> <x a="A" b="B" />
> も
> <x b="B" a="A"></x>
例えばこれが出力結果だとして、なぜどちらになるかわからないのかが謎。

本当にどちらになるのか分からないとしても、出力結果をparseして、
・well-formedである
・xが存在する
・attribute a = "A"が存在する
・attribute b = "B"が存在する
・それ以外のattributeは存在しない
をassertすればいいんじゃね？と思うのだが。

>>421
>例えばこれが出力結果だとして、なぜどちらになるかわからないのかが謎。

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

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

を一般化したいと言うことだろ。

>>422
だから、どうして実装によって結果が変わるのさ?
乱数でも使ってるのか?
同じ入力なら、同じ結果になり、そして自分が実装したコードをテストしようとしてるんだったら、どっちになるかわかるでしょ。

それと、何で一般化したいの？
ランダムな入力でも与えるの？
仮に何らかの理由で一般化したいとしても、parseしてxml node tree objectにしてしまえば、どうとでもなるんじゃないの?
ならないとしたら、なんでならないのか教えて。

つか、単体テストとかユニットテストはやってるのか？
Unit Testing FrameworkとかAcceptance testing frameworkとかを調べて、どうやって妥当かどうかを確認してるのか調べた方がいいよ。
基本は、期待値を自分で用意して比較する。それがもっとも簡単確実。
どうしてもそれだとテストできない場合は、別のやり方がある。
今回は、どうしてもそのケースとは思えない。

テストできないのは、ただ単に網羅的なテストケースをあげる能力が無いってだけだと思うよ

>>418
>俺が理解するXSLTとはスタイルシートのことで、それをテストするというのがよくわからない。
それは「スクリプトはプログラムじゃないからテストするに値しない」と
同程度にナンセンス
XSLTは関数型言語とみなせる（しかもチューリング完全らしい）

>xUnitは知ってるのか
このスレに書き込んでるんだから当然知ってる
逆にXSLT用のユニットテストフレームワークが
存在していることを知ってて書いているのか聞きたいくらい

>>423
>同じ入力なら、同じ結果になり、そして自分が実装したコードをテストしようとしてるんだったら、どっちになるかわかるでしょ。
多くの場合はそうかもしれないけど例外はいくらでもあるでしょ

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

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

有名どころの処理系で問題なければよいという整理の仕方もあるかもしれないが
それを決めるのは俺じゃない

イメージが湧かない人のために「簡単な」例題を挙げるなら

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

テーブルはレコードの集合(set)であって列(sequence)ではない

このテーブルの行と列を入れ替えたような新しいテーブルをXSLTで生成する
XML的にはこんなイメージ
<変換後テーブル>
<カラム1集合><カラム1/><カラム1/></カラム1集合>
<カラム2集合><カラム2/><カラム2/></カラム2集合>
<カラム3集合><カラム3/><カラム3/></カラム3集合>
</変換後テーブル>
この変換後テーブルも集合であって列でない
集合なので重複は許容されないが順序は問わない

XSLTの妥当性をどんな方法でどんなツールでテストするか？
>>412にも書いたが
テストできるかできないかを聞いているのではない

あと例題にケチつけるのは勝手だがそこを議論する気は無い
外部参照があるとか代替グループがあるとか
ちょっと条件を加えるだけで問題が複雑になることは想像に難くないはず

>>428
だから、そのいくらでもあるという例外が起こるケースはどんな場合なのか聞いてるのだが。

>>432
偉そうにしてお前は浮動小数点演算もやったことないのか？

>>433
浮動小数点演算の比較が難しい件と、今回のこととは関係無いと思うが。

>>428
処理系って何？

質問者が一番XMLとXSLTに詳しそうだし、自分の環境も問題も一番把握してるようだから、
これ以上ここで粘っても無理だと思う。

>>434
同じ入力なら、同じ結果になるって妄信している（かのように思える）>>432に
同じ入力でも同じ結果にならない身近な例を挙げただけだ

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

>>435
この文脈で処理系つったら言語処理系だろ
XSLTの場合MSXMLとかXalanとかSAXSONとか

あ、失礼、SAXON

>>437
君は元質問者なの？違うの？
元質問者は、XSLTを使った変換ロジック、つまりxalanなどと同じ立場の変換プロセッサを実装し、それをテストしたいのだと俺は理解したんだが。
そうじゃないとしたら、一体何を実装したんだろうか？

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

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

仮にテスト対象への入力がXSLTではなく、出力がXSLTだとするなら、今度は期待するXSLTとのテキスト比較ではなぜ駄目なのかという疑問が出てくる。

>マニュアルで準備したXSLTが、要件にマッチしているかどうかという意味で妥当かどうかをテストしたい
これだろう

>>440
だとしたら、やっぱこれでしょ。

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

これがなんで嫌なのかわからん。

>>441
その考え方自体を嫌とは言ってない
その一実現手段であるXPath式を使った方法(SchematronやXSLT）は
バグを埋め込みやすいし保守性も悪いと感じていると述べた

何故か？
typoを検出できない（typoってもうまく動作しているようにみえる場合が少なからずある）
大してテスト対象の規模が大きくなくてもアサーションの数が多くなる
しかも似たようなアサーションが並ぶが再利用性は悪い
等々

だから埋め込んだバグを見つける手段（「テストコード」のテストとか）や
そもそもバグを埋め込みにくくする手段
（LINQ使うと文法チェックと自動補完が使えていいよ！とか)等について
何でも良いから意見を聞きたかった

が、ここを見ている人はそんなこと問題に思ったことないらしい

なんだ、そんなつまんないことが聞きたかったのか。

typoがあったらテストが失敗するからいいんじゃないの？
あと、保守性をいやに気にしてるけど、一度書いたテストは保守不要なんじゃないの？

>>445
>typoがあったらテストが失敗するからいいんじゃないの？
>>442
>typoってもうまく動作しているようにみえる場合が少なからずある

>一度書いたテストは保守不要なんじゃないの？
基本はそうだが
ロジック階層の抜本的な変更はそうあるもんじゃないけど
データ階層の変更（項目の追加・名前の変更）は十分にあり得るというか実際にある
メインコードであるXSLTの修正も大概ではあるが
テストコードとテストケースの修正はその比ではなくうんざりする
変更の差分だけ追加テストで済めばよいが必ずしもそうじゃない
済んだと思っても追加の変更で首を絞めることにもなりかねんし

>>446
typoがあってもテストが失敗しないことが多々あるって、そりゃテストコードが糞なだけだ

>>447
もはやXSLTとか関係ないじゃん
どううまくやるかってのはそれこそケースバイケースで、お前がこれまでに出した
情報ではアドバイスできる奴いないと思うわ

話がループするなぁ

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

多くのRDBMSやクエリ言語ではそういう問題は少ないし
SQL関係は情報もツールも充実している
XML関係は情報こそ充実しているものの入門や規格解説レベルのものが多くて
実務上のノウハウに関する情報は多くない

XML関連で重要な働きをするXPath（XQueryを含む）は使う分には便利だが比較的難解
(感覚的には間接参照の概念を理解していてもC++のポインタがハマりやすいのに似ていると思う）

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

そういった背景を無視してXSLT関係ないって言えるのか？
表面的な部分だけ一般的問題に帰着させてないか？

ケースバイケースでも有用な議論はできるだろう
こういうケースならこれでうまくいくって情報は
たとえ直面している問題に適用できなくても価値があるだろう

個別の議論に付き合いたくなければ黙っていればいいだけ
どうせもともと過疎スレなんだし

そもそも何のスレです？

>>1を尊重するなら
「テストしにくいコードをテストする方法教えて下さい」
>ここで言うテストっていうのは
>ユニットテストみたいなものね。
なスレ

今の流れがスレチだと思うなら別のネタでも提供すれば？
どうせgdgdな議論になるか過疎るかのどっちかだ

俺は自分のことは自分だけで説明したいので…

だからさぁ、具体的に困ってることを言わないと話が進まないんだって。
処理系が違えば出力結果が違うのはもうわかったからさ、なんでテストで
処理系を固定してはいけないのかとか、typoが致命的な場合ってどういう
ときかとか、実装が異なるってどういうことかとか、具体的に言わないと
改善案は出ないよ。

それと今どうやってテストしてるのか何で言わないの？
それがわからないと改善しようにも、何を改善すればいいのかわかんないよ。

例えばさ、入力するXMLTをパーズして、テストを自動生成するのができるのかとか、
できたとしてその自動生成ロジックを作る工数とマニュアルでテストを書くのと
どっちが大変かとか、結果の自動判定ロジックはどうかとか、テストを書く人の
スキルはどの程度かとか、俺ら全然わかんないし。

普通は、typoを減らすには、入力データもテストメソッド内でコードで生成して、
同じ文字列リテラルをAssertでも使うとか言う方法があるんだけど、それは
今回使えるかとか、nameとかvalueは1文字にすればtypoとかないよねとか
そのへんどうなのよ。

大量のAssertが嫌とか、じゃぁ目視でテストすればとか嫌み言いたくなるよ。

そうそう、まあ過疎スレなんでいないとは思うが、これまでに評価したXSLTの
xUnotは何で、それのどこが駄目かを書くとか。

って書いてて思ったんだが、最も目的に近いxUnitを改造すればいいんじゃね？

typoもあるし変な文章になったけど、具体的に書けばひょっとしたら経験者がいるかも
しれないし、Googleでも検索にヒットするようにならるから、誰かが来るかもよ。
まあ、ないとは思うけど。

雑談ネタとして挙げたのに面倒な流れになったな

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

>>456
>なんでテストで処理系を固定してはいけないのか
>>428
>身内以外もテストを実行できないといけない
テストまで含めて成果物
自分がミスしていないかチェックする手段を
非公開で持っておくというのも手ではあるけどやっぱり二度手間だよね

>>typoが致命的な場合ってどういうときか
致命的かどうかは状況によるが
XPathで
/a/b//c[@x='X']
と書くべきところを
/a/b/c[@x='X']
と書いても
どちらもXPath式としては有効だし結果は同じになるかもしれない
テストケースはできるだけシンプルにするのでなおさら

>実装が異なるってどういうことかとか
>>429-430の例でいえば
レコードを上からなめるか下からなめるかの少なくとも2つの実装が考えられる
2つのXSLTで出力結果（<カラム*集合>内の要素の順番）は変わるだろう
普通は上からなめるだろうけどそんな制約は仕様にないので
勝手に仮定してテストを書くべきじゃない
全通りのテストを作る方法もあるだろうが組み合わせ爆発が容易に想像できる

>>461
また話が見えなくなったが、テスト実行環境も含めてリポジトリに登録すればいいんじゃないの。

>>462
XPath使うのやめれば？

>>463
ますます話が見えないんだけど、XSLTが二つあったら、それぞれに対してテストケースを
設定するのは普通だよ？

>それと今どうやってテストしてるのか何で言わないの？
>>405の時点で
>結局XPath式使って評価することになって
>Schematronや妥当性を評価するためのXSLTが出来上がるんだけど
って書いているし
>>416でも
>「変換結果の妥当性」を評価するために別のXSLTも使っている
>（別にXPath式を使ったロジックが書けるなら他の手段でも良いが）
って書いてるのはガン無視か？

あちょっとまて。
XSLTって変換プロセッサのこと？
だったら一つに固定することで解決するよね。

>>466
うーん、俺に言わせればそれ全然具体的じゃないんだよ。
例えば、テストを書いてるコードの言語とか、Testing Trameworkは使ってるのかとか、
確認に使うXSLTはどう使ってるのかとか。

今まで述べてきたXSLTはXSL文書のことだよ
変換プロセッサは処理系って書いてるよ

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

>XPath使うのやめれば？
それも名案だね
C#で開発してればLINQ使いたいんだけどね

>>462
//が存在するのがNGなら、それをチェックするツールやAssertを先に通すとかじゃ駄目なの？

っていうか、そういう些末な例じゃなくて、本質的な問題をズバリと言うことはできない？

>>468
>テストを書いてるコードの言語とか
XSLTでテストを書いてるっていってんだろ

テスト対象のXSLTのテストについては
今回はフレームワークは使ってない
・ファイルの更新チェック
・テスト対象のXSLTのXML SchemaでのValidation
・テストケース（XML文書）のテスト対象XSLTによる変換
・テストケースの変換結果のValidation
・テストケースの変換結果の評価用XSLTによる変換
を行うスクリプトを書いて
Webブラウザをコンソール替わりに使ってる

>>469
俺が何に疑問を持ってるかというと、テスト対象のXSLTはどういう性質のものかってこと。
ある特定の目的のために、10個20個あって、それぞれに50個のテストを書くようなケースなのか、
何百もあって、個別にテストケースを書くようなことはできないのか。

それと、LINQで劇的にテスト工数が削減できるなら、使えばいいのにって思うんだけど。
なぜ駄目なの？

>>471
その「を行うスクリプト」が何だか知りたいんだけど。
あと、Testing Frameworkを使わない理由は？

>>470
だからそれをチェックするツールを知ってるんなら教えてくれって話

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

>そういう些末な例じゃなくて、本質的な問題
何か壮大なスペクタクルでプロジェクトX的なカタルシスを期待してるのかどうかしらんが
typoは所詮typoだよ
とはいえテストが事実上無効化されるという点で馬鹿にできない

>>472
>テスト対象のXSLTはどういう性質のものかってこと。
仕事の内容だから具体的に書く気はないが
XML Schemaにして400KB程度のスキーマを持つ
データベースのインスタンス文書から可視化できる要素を抽出し
SVGみたいなXMLベース形式に変換するものを書いている
そんなXSLTが数十個

インスタンス文書のパターンは無数にありどれだけテストケースを書くかは裁量による
XSLT内部のtemplate要素は十個程度なので
感覚的には1個のXSLT文書に対し数十個くらいテストケース用意すれば十分だろうという認識
実際そんなにはテストケース用意できてないけど

>>472
>LINQで劇的にテスト工数が削減できるなら、使えばいいのに
駄目じゃないけど劇的というほど効果がある訳でもないからね
個人的にはXQuery書くよりかは若干精神衛生に良いくらい

テストのためだけにVisual Studio要求するのもアレだし
そもそもLINQってどのくらい一般的なのか知らない
少なくとも自分はホビーでしか使ったことない

>>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ブラウザだけあればテストできるし使う理由もないかなと

そういう意味で気に入ったフレームワークや便利な使い方があったら
教えてくれると嬉しい

>>465
多分誤解している
XSLTは少なくとも2つ考えられるが2つ書くわけじゃない
リファレンス実装相当を一つ示すだけだ
第三者が別の実装をするかもしれないが
それを想定して複数のテストコードを用意するのは現実的じゃない

繰り返すがテストコードも成果物なんだ
間違っているものを間違っていると言えないテストコードは単なる無能だが
正しいものを間違っていると判断するのは仕様を満たしていない明らかな不良品

じゃあ、間違っているのを正しいと判断するものは？

>>480
正しいと「明示」するんなら同様に不良品だろう

ただテストは誤りを見つけるもので
誤りがないことを示すものじゃないってのは常識

常識とか言われると、じゃあリグレッションテストって何ですかとか言いたくなるわけですが。

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

色々質問して回答に手間かけさせてごめんね。

リグレッションテストも
変更に伴う誤りを見つけるためのもので
誤りがないことを示すものじゃないだろ

謝るくらいならテストに対する考え方とか
自動化の方向性について意見を述べてくれてもいいんじゃないか
強制する気は毛頭ないが

>>457とかちょっと自動化に夢見すぎ
テストを自動生成するためには形式的な仕様がないといけないが
実装から仕様を導出することは一般に困難だ
（仕様書読むよりソースコード読んだ方が分かりやすい！
なーんてことはあるかもしれないけどね！）

テストカバレッジを上げたい
（テストカバレッジを上げることでバグの検出率向上が期待できる）なら有効だろうけど
純粋にバグを見つけたいんならあんまり意味ないな

>>483
いや、リグレッションテストは、変更によって他が壊れていないかを確認するテストで
バグを見つけるものではないよ。ほら、こういう所にテストに対する考え方の
違いがある。

自動化は、テストデータ生成もテスト実行も結果確認もプログラムでやるのが基本。
CIツールでコミットをフックしてテストを実行できて、結果も取得できなきゃ意味ない。

>>484
別に夢なんか見てないよ。日常。
自動化は、実行と結果確認が対象。
テストそのものを自動生成できるかどうかは、場合によるよ。
コードで簡単にparseできるものがテストターゲットなんだから、何か自動化
できるものがあるんじゃないかって程度だから、一般に無理とか言われても困る。

例えば、XSLTを読み込んで、お決まりのテストパターンを含むテストクラスを自動生成する
スケルトンジェネレータとか、その程度でも誤りと手間が減るでしょ。
今回のケースで、それが可能かどうかはわからないけど。

>>485
他が壊れている状態ってのは誤りじゃないの？
正しいの？正しくないけど誤りでない状態があるの？
まぁ誤りじゃないというならそれでもいいけど
>>481の意味するところは
テストは「そういった不都合全般」を見つけるもので
「そういった不都合全般」がないことを示すものじゃないってこと

用語の解釈に差はあってもテストに対する考え方の違いじゃあないだろう

>>485
>CIツールでコミットをフックしてテストを実行できて、結果も取得できなきゃ意味ない。
できた方がいいだろうけど意味ないは言い過ぎでは？

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

既存ツールなら喜んで使うが自作するとなるとやる気しないね
スキーマによるValidationが有効で
お決まりでないテストパターンで合格しながら
お決まりのテストパターンで不合格になる場合ってのがそうあるもんじゃないし

勿論typoってのが
>スキーマによるValidationが有効で
>お決まりでないテストパターンで合格しながら
>お決まりのテストパターンで不合格になる場合
に該当する場合があるけどね

テストには、バグを検出するという目的と、正しく動作するという保証を与えるという目的がある。
リグレッションテストは、後者の方。これは言葉の解釈の問題じゃないよ。テストというものを
どう捉えてるかの問題。Acceptance testも明らかに後者。
正しく動作するという保証を与えるという観点が無いから、お決まりのパターンを軽く見てるんじゃない？

あと、スケルトンジェネレータは自分で作るんだよ。
俺ならこういうのを数時間で作っちゃうし、嫌だなんて思わないよ。むしろ、楽しい。

> 数時間で作っちゃうし

なんか、仕事のペースじゃないな
そんなゆっくりとしてちゃ仕事にならんだろ。

>>492
数時間でできあがれば、次の1分で50ファイルそれぞれに20個位のテストが生成されて、
次の1分でビルドして、10秒で1000テストケースの実行が終わる感じかな。
遅くてすみません。

自動生成されたテストケースに
何の意味があるんだろうか？

>>491
テストには、バグを検出するという目的と、
正しく動作するという保証を与えるという「心意気」で行うものがあるだろう

が目的が何であろうと
テストによって正しく動作するという「保証」は極々稀な場合を除いて得られない
>>479-481の流れはそういう話だ

>>494
自動生成の限界については今更議論することじゃないだろう

本格的に自動生成を考えているならこっちで
【Alloy】形式言語による仕様記述【VDM】
http://toro.2ch.net/test/read.cgi/tech/1357387746/

自動生成の話じゃなくて、
テストケースを自動生成することに
何の意味があるのかってことなんですが？

自動生成プログラムに
間違いがあったらどうするんだ？

>>497
その問題はテストケースを手動生成すれば解決するのかい？

限界はあるけど、限界があるから何もしないんじゃなくて、限界の範囲内で
出来ることをやればいいんじゃないかな。

>>498
自動生成されたものは
どれだけあっても
一個だって言ってるんだよ。

>>497
今回のXSLTの話とはちょっとずれるけど、既知のテストとして有用な値というのがあって、
例えば0とか1とかINT_MAXとか、""とかnullとか存在しないパスとか、￥とか。
それらを与えるテストを自動生成できれば、assertなしでも少なくとも呼び出せて、
例外が発生しないとか、起こるはずの例外が起こるとか、その程度はできるよ。
場合によっては、いくつかのassertionも自動生成できるかも。

>>501
そういうのはコンパイラの型チェックにやらせたほうがいいよな。
明らかに駄目なケースというのは、
コンピュータであってもわかるはずだ。
ならばテストを書かずにチェックできたほうがいい。

>>502
int sum(int a, int b)をどうやってコンパイラにチェックさせるの？

だからそういう静的解析の類は
形式言語スレの方が歓迎されるよ（たぶん）

>>503
それに対して

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

テストを自動生成できるって話だろ？
できねーよｗ

>>505
出来ないのか。
じゃ、マニュアルでテスト書くしかないね。

自動生成したテストっていうのは
要するに同じテストを何度もしているに
過ぎないんだよ。

>>507
そう思うのは勝手だが
そう思わない人を何のデータもなしに否定しないでほしいね
そう思わない人の多くはきっと>>507の考えている欠点を理解してるよ

>>508
じゃあ先にデータ出せと。

どんなコードに対して、
どんなテストを自動生成してるんだ？

>>507
0を与える場合とINT_MAXを与える場合とでは、違うテストのような気がしてるんですが、
俺の気のせいでしょうか。

>>510
それを、いくつものファイルの
いくつもの定義に対して
自動生成しても意味が無いってこと。

まあ、その場合は2つだ。
ファイルがいくつ有ってもね。

コンパイルの型チェックにできるテストは「aとbに+をすることができるか？」だけ。
「sum関数に0とnanを渡してnanを返すか？」みたいなテストはできない。
だから>>501みたいなテストを型チェックでやらせようとする>>502はアホ。

>>510
何が2つなんでしょうか。
xUnitを使ったことありますか？そして、それに付属してたりするスケルトンジェネレータは使ったことあります？
入力ファイル数分のテストクラスができて、その中には公開メソッド数分のテストメソッドが作られます。
これ、いくつですか？

自作のスケルトンジェネレータを作るときに、上記に加えてパラメータの型に着目したテストも
自動生成できるわけなので、さらに数は増えます。

> 入力ファイル数分のテストクラスができて、その中には公開メソッド数分のテストメソッドが作られます。
０じゃねーの？
どうせそのメソッドの中身空だろ？

>>512
> 「sum関数に0とnanを渡してnanを返すか？」みたいなテストはできない。

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

つまり自動生成できないわけだよ。

後付けのテストをする必要があって、尚且つ大量のテストを書く必要があって、
更にテスト対象のドメインや技術に詳しければ、自分で好みのスケルトンジェネレータを
作れるよねってことを言ってます。
そして、それらのテストは、ただ実行できるだけでも価値があります。

>>513
> 自作のスケルトンジェネレータを作るときに、上記に加えてパラメータの型に着目したテストも
> 自動生成できるわけなので、さらに数は増えます。

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

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

その型を使っている所全部にテストコード入れても意味が無いって言ってるんだよ。
同じテストを何度もやってるにすぎない。

>>515
数学関数ならnan受け取ったらnan返すよ、普通

>>516
本当に大量のテストをやらないといけないのかを考えることだ。

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

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

数だけ多ければいいと思ってるなら
効果的なテストという発想にはたどり着けないな。

>>515
最近はSMTソルバを使ってテストやテストケースを作るのが流行ってるよ
使える使えないはともかくできるできないでいえばできる例は実在する

>>517
sum(0,0)もdiv(0,0)も型は同じだけど別モノに思えるけど？
まぁ同じ同じじゃないは主観だけどね

>>518
それなら、「数学関数」というカテゴリを作って、

そのカテゴリに入っているものは、
nanを返すか？というテストだけでいい。

>>517
あくまでもスケルトンなので、assertが足りないなら追加するし、メソッドが不足しているなら
追加します。

>>522
それはテスケースを自動生成したとは言わんだろｗ
お前が手動でテストケース書いてるじゃんか。

>>519
普段、C0カバレッジで言うと、どれくらいの感じでテストしてます？

>>521
え？そういうドメイン特化したテストケースの話じゃないの？

>>523
テストケースは自動生成してますよ。
xUnitのスケルトンジェネレータでいえば、各メソッドにつき一つのPositive Test Caseを
生成しているといえます。

全部をマニュアルテストするとか、全部のテストをマニュアルで書くとかいうのは絶望的だから、
ちょっと楽できるスケルトンジェネレータを作ってみてはいかがですか、くらいのことですよ。

上手くはまれば、かなりの部分を自動生成できて美味しいよって感じです。

>>526
えと、そのテストケースを通るようにコードを書くのか？
それともそのテストケースをこれから修正するのか？

今からテストケース作るんだよな？ｗ

ジェネレートしてしまうと
修正が大変になるからやらないほうがいい。

代わりに、テストケースを一個書いて
それらを複数の関数に適用すればいい。

>>528
テストケースというのは、テスト項目とほぼ同じ意味で使ってます。
ジェネレートされるのは、テストコードです。
もちろん足りないコードは自分で追加します。
自分が作るスケルトンジェネレータは、テスト対象のことがよくわかってるので、
メソッド呼び出しコードも作れたり、assertも作れたり、例外を期待するコードも
作れたりするでしょう。

>>530
ジェネレータ無しで
普通に作ればいいのでは？

同じテストは書くだけ無駄なんだからさ。

>>528
ここで言うテストケースはテスト（テストフィクスチャ）に食わせる入力のことじゃないの？
テストフィクスチャと勘違いしてないか？

テストケースの話だって言ってるだろ？

もしかして、この馬鹿は
テストフィクスチャ（テストデータのようなもの）を
テストケースと言ってんのか？

>>529
その方がいい場合もありますね。そして多くのxUnitでは、テストケースを配列で表現して、
同じテストメソッドをその配列数分呼び出す機能があったりします。
そういうのが良い場合は、そういうスケルトンをジェネレートすればいいですね。

他方で、１テストメソッドにつき１assertion派という人たちも存在してます。

>>534
お前が言ってるのは、テストケースじゃなくて
テストフィクスチャだ。
あほめ。

もしかして「スケルトン」の意味わかってないんじゃないのか？

スケルトンの意味は骨組み。
中身（テストケース）が無いものだよ。

>>531
ジェネレータがあった方が楽な場合の話です。
後付けで大量のテストを書くはめになったときとか。

ユニットテストはじめたばかりなんでしょ？
xUnitの実行結果に書いてある
実行テストケースの数値を無意味に増やすことに
命かけてるんでしょ。

>>537
もしかして大量のテストが偉いと思ってる？

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

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

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

もし、コードの行数が多ければ多いほどいいと思ってる会社みたいに、
テストケースの数も多ければ多いほどいいと思ってる会社に
勤めてるならご愁傷様ｗ

で>>520は正真正銘のテストケース自動生成だと思うけどどうなの？

>>535
いいえ、テストケースです。
テストケースとは、例えばsum()で言えば、
・どちらの引数も0の場合
・どちらもINT_MAXの場合
それぞれが別のテストケースです。

>>541
そのテストケースは自動生成されたものじゃないだろ？
出来るわけがないんだよ。

どちらの引数も0の場合の挙動は
sumとdivで違うんだから。

>>539
100個のクラスがあって、それぞれ10個のメソッドがあり、それぞれにpositive/negativeなテストを
ひとつずつやると、それだけで2000テストケースになります。

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

ところで、普段はC0カバレッジはどんな感じでやってます？

>>542
ケースは自動生成してます。
コードは完全じゃありません。
スケルトンなので。

100個のクラスがあって、それぞれ10個のメソッドがあり、それぞれにpositive/negativeなテストを
ひとつずつやると、それだけで2000テストケースになります。

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

だから自動生成できないのです。

>>544
スケルトンは、テストケースじゃないぞｗ

なんか、テストの幻影に騙されてる人みたいだな。
数値ばっかり気にして、その意味まで考えられていない。

テストケースは自動生成し、それを実行するスケルトンコードを吐き出すのが
スケルトンジェネレータです。

テストに漏れがあるかどうかは
カバレッジ測定でわかるからどうでもいい。

関数の仕様を考えず、ただ実行したという事実だけを
調べる形だけのテストはいらない。

>>547
普段C0カバレッジはどんな感じでやってますか？

テストケースのスケルトンは
テストケースではありません。
ただの関数定義です。

テストとしての意味があってこそ
テストケースと呼べるのです。

>>549
カバレッジでわかるのは、C0カバレッジでいえば命令網羅率でしかなく、ケースのカバー率はわかりませんね。

>>551
テスト設計時にテストケース抽出なんて言いますが、あれはいったい何なのでしょうね。
テストコードなんか存在してないのに。

ところで、普段C0カバレッジはどんな感じでやってます？

だから>>546が期待しているような自動生成はまだ未完成なの
>>546が無駄だとか悪だと思おうが未完成なりに使い道はあるの
しかも研究開発は継続的になされているし
一部のツールには既にスケルトンジェネレータ以上のものが実装されているの
まだ何か言いたいことはある？

テストなんてやったこと無いので
実のところ分かりません
javac Hoge.java でエラーが出なかったらOKの世界ですから〜

>>554
テストケースの自動生成はできません。
テストケースのスケルトン（骨組み）は
テストケースではありません。

>>553
> テスト設計時にテストケース抽出なんて言いますが、あれはいったい何なのでしょうね。

最初っからテストコード書けばいいのに、
コードかけないから
エクセルで書く行為じゃねーの？

>>556
スケルトンがテストケースだろうがテストケースじゃなかろうが
テストケースの自動生成の実例はあるっつってんだろーが
都合の悪いものは見えませんってか？

もしかしてコーダーじゃねーの？

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

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

だから（エクセルからの）ジェレネータとかいう話になるんだろ。

>>558
じゃあ、その都合がわるいものを
見せて下さい。

あるんでしょう？

スケルトンの自動生成の実例を見せられたって意味ないよｗ

>>559
私も普段はコードとテストは同時に書きますよ。
後付け大量の話は、XSLTの人の場合ですね。
後は、ライブラリやCOMなんかの第三者検証の場合とかですね。

> 後は、ライブラリやCOMなんかの第三者検証の場合とかですね。

ん？ もしかしてテストコードのレビューをやらないで
自分で一からテストコードを別実装してんの？

いや、それこそ自動生成できないだろ
ソースコード無いんだから。

>>563
そのテストコードってひょっとして開発者が書いたものですか？
だとしたら、それはないですね。第三者検証をするんのであって、
開発者テストのレビューをするのではありません。

>>560
めんどくせー奴だなぁ
実際にオープンソースで動くものの例としてはこれとか
http://llvm.org/pubs/2008-12-OSDI-KLEE.pdf
この論文自体には自動生成の具体例がないけど関連文献でも読んでみれば？

自動生成の具体例がないけど
自動生成の具体例がないけど
自動生成の具体例がないけど
自動生成の具体例がないけど

机上の空論じゃない、実際に動くテストコード生成ツール
https://code.google.com/p/crest/

ソースコードをOCamlで書かれたツールで解析して、
分岐構造を抽出し、求めた分岐条件をSATソルバーにかけて
全分岐を網羅するための入力値を得て、テストコード生成までやる

>>562
お前の話の本筋を否定する気はないが
XSLTの人はコードとテストを同時かテストを先に書くぞ？
by XSLTの人

>>569
勘違いしてました。申し訳ない。

カバレッジを上げることが目的になってしまってるな。哀れ。

ここらで一旦アイちゃんの出番だな。

だれでも一度は アイ!アイ!
それが最高の アイ!アイ!
だれでも夢見る アイ!アイ!
それはナイショ DE アイ!アイ!
ア・ア・ア・アイ! ア・ア・ア・アイ!
Fu!Fu! Fu!Fu! ア・ア・ア・アイ!
ア・ア・ア・アイ! Fu!Fu!

バグが10個あるなら10個のテストで検出するのが理想だねなんて
以前西先生がどこかでおっしゃってましたが、普通はそんなこと
できないわけで、じゃあどうするかというとある程度カバレッジを
上げるのが、最もコストの低いやり方だと思います。

第三者検証ではブラックボックステストを行うので、コードのカバレッジは
分からないので、漏れのないテストケースを考える必要があります。

> 西先生
だれ？


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

先生だもんねｗ

プログラミングスレ
http://hayabusa.2ch.net/test/read.cgi/news4vip/1363452391/

>>575
西康晴

>>577
了解

約 6,300 件 （0.32 秒）

テストを分かってないやつばかりだな

わかってる人が今から説明してくれるそーです

わーい

テストを分かってるかテストする方法を教えて下さい

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

2chで煽って優越感に浸るやつじゃありません。

テストを分かってるかテストする方法をテストするところから始め給へ

if テストを分かっている
return 分かっている;
else
return 分かってない;

return テストを分かっている ? 分かっている : 分かっていない;

if ! 何故バグをつぶすべきかを分かっている
return 分かっていない;
if ! どうやってバグを発見するかを分かっている
return 分かっていない;
if ! バグの潜みやすい設計・構造を分かっている
return 分かっていない;
if ! どうやってバグ発生が収束したことを知るかが分かっている
return 分かっていない;
else
return 分かっている;

test

てす

GUIのテスト何使ってる？

GUIつってもWebとローカルじゃ違うと思うけど

>>589
人間

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

てのはどう?

>>590
すまん
今はローカルのアプリのテストしようとしてる

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



まだツール選んでる状態なんだけど，操作するだけじゃなくて
ある程度，実行とか結果の確認とかまでカバーしてくれるようなフレームワークないかな
JUnitのGUI版みたなやつ
ってかGUIのテストって情報少ないな

GUIて操作性やデザイン的な部分の設計がクローズアップされやすいですね

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

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

となる感じかな
でも、人間相手の部分はどうしても泥臭いところが出てきちゃう

ビジョンというかガイドラインというか、方針か。
それを定めて一貫して作れば幾分緩和される。
思い付きで積み上げると、いつかどこかで破綻する。

>>593
バカはどこまでもバカなんで万人に合わせるのは無理
万人にあわせたGUIはソースも設計もgdgdになる

1画面にすべての情報が出ている方がいい人 / タブや階層で機能ごとに別れているほうがいい人
マウスだけで操作したい人 / 出来ればキーで操作したい人

性格の違うものを混在させるとgdgdになるので、大切なのはデザイナ/設計者の「整理整頓能力」

>1画面にすべての情報が出ている方がいい人 / タブや階層で機能ごとに別れているほうがいい人

Windows8/8.1のスタートですねわかります

デスクトップがアプリやファイルのアイコンで一杯一杯の人

>>575
こういう考えがクソ品質コードを生み出すんだろうなあ

つーか、テスト屋で西先生知らないとか、不勉強にもほどがあるだろ…

レジストリの値を取得する関数のテストって
テスト用に目的のレジストリを書き換えてやるのが一般的？

今時レジストリを直接いじるのもどうかと思うけど

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

複数プロセスが同時に同じレジストリキーにアクセスとか
読み書きの遅延がクリティカルだとか
面倒なこと考える必要がなければどうやろうと大差ない

単体テストレベルならいちいちレジストリにさわらない
ただしセキュリティ権限で台無しにされないように
初回だけは実アクセスのチェックも必要

そういえば HKLMとHKCUの内容が重なる項目があって意味不に陥ったこともあったな

>>601
VMwareで仮想環境作っておけば、テストでレジストリ壊しても平気。

>>605
今時ならvagrantとか使えばそれなりに仮想環境は簡単に戻せるからな。

>>602
>>603
>>605
ありがと
プログラムはレジストリ値取得部は完全分離
他の部分はモック使ってテスト
レジストリ部は仮想環境でいろいろレジストリ値いじってからテスト
重要なところは本番と同じ環境でテスト
って感じでやってみます

例外が発生するかのテストってどこまで厳密に評価してる？
別に例外に限った話じゃないが戻り値の評価と機構が違うという点に着目して

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

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

などなど

ホワイトボックステストが前提なら3番目もアリだけど
対象コードが呼び出すコードの例外まで考えるとテストの保守が大変だなぁとか

>>608
Aを発生させた後でどうやってBを発生させるかって話？

例外Aが発生しても例外Bが発生しても仕様上は間違いでない（仕様が曖昧な）場合
どういうテストを書くかって話でしょ

両方キャッチすればいいだけじゃね？

それも一つの解だけど
バグの見逃しが増えるよね？

意図とは違う箇所で「たまたま」例外が発生していたってのは
ありがちなバグ

テストが書きにくい項目で、どうしても気になるとかコストが見合うということなら、ホワイトボックスでカバレッジテストしたらいい。

ごもっともだけどその判断が難しいんだよね

自動テストケース生成が
誰でも簡単に使えるようになればいいのに

>>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.");
}

>>612
だから例外が発生しないケースもテストするんだろ？アホでつか？

ひょっとして、テスト対象のモジュール以外のモジュールが発生する例外も含めてテストしようとしてるのかな？
基本的に、テスト対象のモジュールで明示的にthrowしている例外だけテストすれば十分だよ。

>>616
それは当然やるとして
たまたま例外が発生してバグを見逃す事例に対しては無力だと思うが

というよりそれをやっても見逃すから「たまたま」って言うんじゃないの

>>618
たまたまテストを通ることがあるってのは、例外に限らんだろボケ

>>618
> それは当然やるとして
> たまたま例外が発生してバグを見逃す事例に対しては無力だと思うが

具体的には、どういうケースの場合無力なの？
コードで説明して。

>>620
コードで説明しないと話にならないとか上から目線で言って
コード例を示せば
自分はそんなミスしないとか
テストじゃないくてコーディング規約で対処するとか
いちゃもん付けてくんだろ？

それでもあえて具体例を示すなら

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

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

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

もちろん
例外が発生しないケースで例外が発生すれば
バグの発見に至るのでそれ自体は有効だが
NULLチェックが無いことを見つけるには無力と言っていいだろう

NULLチェック漏れに気づかないはずがないと思うかもしれないが
未定義動作をやってしまうと
コンパイラ様が気を利かせてNULLチェックを消してくれたりする

自分の使ってる言語ではそんなこと起きない？
静的解析ツール使う？
それはよかったね！

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

それってパラメータチェックの話？
だったら、普通はinvalid_aurgument的な例外をthrowするんじゃないの？

>>622
ばか？別に難しくもなんともない。
つーか、一番簡単な類いのテストだろ。
あほらし

>>624
どんな例外投げるかなんて議論してないし
言語や文化で様々なのにこちとら関知しねーよ

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

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

>>625
どこまで厳密に評価するかの判断が難しいだけであって
そりゃあテスト自体は難しくもなんともないだろう
つか>>622は>>620への回答のつもりなんだが

>>608で書いてた問題意識と全然関係ないやん
馬鹿丸出し

全然関係ないって
>>612のようなことを一切考慮せずに
>>608のA or Bの条件でそれぞれ例外A、例外Bを発生させるコードの
テストを考えちゃうってこと？

そういう割り切りも有益だが
他人を馬鹿にできるほど褒められるもんでもないと思うが

だーかーらー、

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

全く関係ない、

単体テストの

基本中の基本でそ。

Webのuiのテストにそろそろseleniumとか覚えないとだなーっておもって半年位たってしまった

>>626
> どんな例外投げるかなんて議論してないし
俺もそれは議論してないよ。

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

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

> java.lang.NullPointerException以外はぬるぽと認めない
> という主張なら否定する気はないが
> そういう主張じゃないんだろ？
全然そういう主張じゃありません。

俺は単純に「たまたま例外が発生してバグを見逃す事例に対しては無力」というケースが
どういうものなのかを知りたいだけなの。

特に何かに関して議論したいとは思ってません。

>>631
>テストコードではその例外がthrowされたかどうかをチェックすればいいよね
テストコードの良し悪しはともかく
それがバグを見逃す事例って話をしてるのに「いいよね」で片付けちゃダメだろ
何でいいと思うのか説明してもらわないと話が平行線だ

最近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)を見つけることに関しては無力

先に言っとくが
>>634のコードの問題点の指摘とか解決策の提案とか望んでないからな？
言うのは勝手だが俺に向かって言うなよ？

普通に静的解析で見つかるバグだろ

>>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++での場合だけど。

いや、こうか。

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");　　// こんなマクロあったっけか？
}

>>637
そういうケースってどういうケース？
それはバグがあることが分かっているから
できる判断じゃないの？

>>639
> そういうケースってどういうケース？
> それはバグがあることが分かっているから
> できる判断じゃないの？
いや、そうじゃない。

「そういうケース」というのは、プロジェクト内の至る所で同じ例外クラスがthrowされるケース。
だから、特定の場所で正しくエラー判定がなされ、例外がthrowされたことを確認すればいいわけ。

>>634
それ、検出対象が例外なのかどうかと全く関係ないでしょ。
単なる制御構造の条件検出の一般論。

てすと

てすと

テスト

てすと

> なんか誤解してるっぽく見えるからそれをときたいだけなのに原理主義だの教条主義だの
> テスト厨だのって言われるのは心外っすね。。こちらだって別に銀の弾丸だと思ってないし、
> ただ誤った理解を訂正したいだけなのに。。

正しい理解が為されればdisられないという考えがすでに宗教。
だから原理主義言われるんだよ。

てすてす

クソスレ

クソレス

うんこ

ソフトウェアカスタマイズ用のAPI使ったモジュールはテストしにくいよな
テスト用にArquillian的なギミックが用意されてれば別だが

気合い

外注に投げる

まんこ

害虫一択だな

テステス

必要な予算を見積もって外注に投げるでOK

テストのしやすさってどうやってテストするの？

テストをしてみればいい

てすてす

こういう場合の単体テストってどの単位にどう記述すればいいの？

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

っていう、ため息がでるほど素晴らしい()設計なんだけど。
はぁぁぁぁ、リファクタリングしたい

>>661
struts知らないしbeanがなんだかわからないけど、そのbeanとやらのMockを作ってやればいいんじゃないのと
ちょっとググったら、Struts TestCase for JUnitなるものが存在することがわかった。
これは試した？
あと、他にもxUnitをサポートするツールやライブラリがあるかもよ？

>>661
struts知らないしbeanがなんだかわからないけど、そのbeanとやらのMockを作ってやればいいんじゃないのと
ちょっとググったら、Struts TestCase for JUnitなるものが存在することがわかった。
これは試した？
あと、他にもxUnitをサポートするツールやライブラリがあるかもよ？

beanは大量のメンバにゲッターセッター付いただけの値保持クラス
だからモックにしてもあんまり意味はないかも？
なにも機能は持ってないが、処理から処理へ情報を渡す箱

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

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

いっそリクエストパラメーターと出力されたHTMLの組み合わせだけに着目して内部全部ブラックボックス扱いした方がマシなのかな？

>>664
> xUnit使ってキックできるの分かるけど・・・
> どっちかというと、そこでどんな単体テストを設定すれば
> こいつの正常動作を保証できるんだろうっていう悩み
Strutsを使うと何をどう強制されるのかわからないけど、
beanを受け取ってHTMLを出力するメソッドだけが公開されてるなら、テストは絶望的だね。

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

> いっそリクエストパラメーターと出力されたHTMLの組み合わせだけに着目して内部全部ブラックボックス扱いした方がマシなのかな？
これしかないかも。

コントローラーにロジックが詰まってるとはこれ如何に

えっ？