テストしにくいコードをテストする方法教えて下さい
ユニットテストみたいなものね。
人間がぽちぽち操作してやるテストじゃありません。
言語訓練のために立てたものです。
アイと研究員とのやり取りに利用するスレッドなので、
関係者以外は書きこまないで下さい。
京都大学霊長類研究所
どのように書き換えるのですか？
っていう厨2病のテストエンジニアが主人公の漫画でも小説でもいいから書いてくれ
コードが単体テストし難くなっている原因による
その単体テストがし難くいコードが具体的に示されるまでは、
テストし難い部分を切り分けるという極一般的で大雑把なアドバイスしかできない
マウス操作やキーボード操作、メッセージを発行を
スクリプトで自動制御するアプリを DL してくるか自作して、
それで GUI 部分をテストする
もちろんその前に、ビジネスロジックなどGUI以外の部分のテストは済ませておく
（当然、ちゃんと切り分けられていることが前提だが）
ついでにネットワーク処理のテストは、
たしか任意の負荷をかけられるテスティングツールがあったはず
もう少し具体的に言うと、
アプリ側にGUI操作する度にログを吐き出す仕組みを作っておき、
自動操作スクリプトで操作させた結果のログと期待するログとを比較する
自動でやるの厳しいよね
どうして？
レガシーコード改善ガイド
逆にネットワークから流れてくる同じデータ流せばいいから簡単そう
Web系ならそうっすね
高すぎる
・居眠りしてる間に小人さんが書いてくれた
・設計のバグ
・コーダーのバグ
とかのこと？
いや、写経するだけの人っているじゃん？
「写経」というのが、詳細な設計情報をただ単にコードに落とすというのを指してるとすると、
そんな詳細な設計書を書く所がいまだに存在するのかという疑問になる。
写経がなんだかわかりませんが。
とにかく、特殊な分野の人なんですね。
いや、そうでもないよ。
おそらく君が日常的に接しているソフトの大半はその写経で作られてる。
その写経とやらが具体的にどういう行為なのかわからんのだが、
詳しく説明してみてくれんかな
コーダーとやらはその設計情報通りに単にコードに落としてるだけなので、
テストし辛いとしたらコーダーのせいではなく、設計者のせいだね。
君時代に取り残されてるよ
コーダってもうWeb業界でしか使わないよ
うん、そういう人たちはPGって呼ばれてるね。
詳細設計書と呼ばれる自然言語で書かれたゴミしか
生産できないバカの雇用を守るために存在するよ
本質的にテストでは欠陥が存在しないことが証明できない
つまりこれからは形式的手法の時代だ
勿論そんな時代は来ないがな！
たとえば、写経してできたコードが
クイックソートのコードだとして、
そのクイックソートの詳細な設計書ってのは
どんなのだい？
三角形を更に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;
}
全部同じ方向に回ってたんじゃ穴が開くんだけど。
あと、関数のテストだからテストコードの作り方で教えてもらえるとありがたいな。
「穴が開いたりすんだよね」 と言うが、
穴が開いたかどうかを君はどうやって認識してるんだ？
同義だが、正しい方向かどうかを「君は」何を以て判断してるんだ？
前者は出力した画像
後者は理屈(理論上の正しい計算式)
画像での確認だけど、ある頂点の組み合わせを指定して
三角形に穴が開くことは解っても、どんな頂点の組み合わせでも
穴が開かない事を確認するのは難しいんだよね。
結局後者の理屈だのみ。
> どんな頂点の組み合わせでも
> 穴が開かない事を確認するのは難しいんだよね。
本当に難しいのか？
細分化する前の多角形を塗りつぶした画像と、
細分化した後の全ての三角形を塗りつぶした画像は、
（細分化が正しく処理されれば）ぴったりと一致するのでないのか？
思考の出発点としては画像を用いてもそれほど難しくない思うぞ
頂点座標の選び方次第で、辺のめぐり順が間違ってても、
一致することもあるんだよね
このケースではハーフエッジをどう使うの？
穴が開くってのは、陰面消去てきな話じゃなくて、
座標の誤差で三角同士の間に1〜2pixelぐらいの穴が
開くってことね。
それはそもそもアルゴリズムが間違ってるんじゃね？
表示部分で浮動小数の座標を受け付けないようになってるとか。
あと、ここで聞いてるのは、バグの潰し方じゃなくてテストの仕方ね。
>>38は正しく動くけど、式が正しいか検証するためのテストはどうしたらいいってのが本題です。
そんなもん、テストで検証することじゃなくてコードレビューでもして
チェックすることだとおもうが。
(テストで確認するとすれば、境界値の確認とかだろう)
テストってのは「これだけの動作確認をしたところ、問題ありませんでした」ってのを
示すためのものであって、それ以上のものではない。
1000x1000は保証するとして、1000x1000の座標全ての組み合わせを
試せばいいんでしょ。問題は、その結果確認を如何に自動化するかだけど
確認なんだが、細分化してできた全ての三角形について、
それをレンダリングするとき、頂点をたどる方向は同じ順だよな
たとえば全て反時計回りに頂点をたどるとか
（たとえば OpenGL を使って三角形をレンダリングするならそうなる）
それを前提で話すんだが、細分化してできた隣同士の三角形について、
それらが共有する辺のハーフエッジは互いに逆方向を向いている
もし同じ方向を向いていたら、どちらかの三角形が裏を向いていることになる
（どちらの三角形かは時計回り、反時計回り、どちらを正方向とするかによる）
これを使って結果の正しさをテストできるはずだ
テストではなく正しさを「証明」したいのなら構造的帰納法を使う
もし、最初に確認した私の認識が違っているのなら、
私の考えを改めないといけないから、>>40 の意味を詳しく教えてほしい
回転方向は一定じゃないよ。三角で表現すると難しいから四角で表すけどこんな感じ。
← → ←
↓ ↑ ↓ ↑
→ ← →
３個の四角のそれぞれ隣接する辺が逆向きにならないようにしないといけない。
逆向きにすると四角同士が共有する頂点に誤差が発生し、頂点が隣接する部分に穴が開くんだ。
だから、全ての辺のめぐりを同じ方向にすることはできないよ。
これが三角形でも発生するわけ。
共有する辺のハーフエッジを互いに逆向きにしようと、同じ向きにしようと、
そんな事で隣り合う三角形の間に１ピクセルでも隙間が出ることはない
今時の普通のレンダリングエンジンを用いている限りあり得ない
（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 を読んでそれくらいは自分の環境に合わせて知恵を働かせて読み替えてほしいのだが
だから、「コーダー＝写経する人」ってどんな人達なのか説明しろって
どうやってテストするも何も、テストケース毎に引数を与えて戻り値チェックするだけだろ
> 「写経」というのが、詳細な設計情報をただ単にコードに落とすというのを指してるとすると、
という前提条件の元で進んでたと思ってたんだがな。
>>26
>おそらく君が日常的に接しているソフトの大半はその写経で作られてる。
↓
>>31
>コーダってもうWeb業界でしか使わないよ
↓
>>32
>うん、そういう人たちはPGって呼ばれてるね。
PGと呼ばれてる人の定義は？
コーダの定義は？
何をやってるのかわからんが、穴が開くかどうかとテストのしづらさにどんな関係があるんだ？
設計がどんなのか言ってみろって。
たとばクイックソートの設計。
その設計を ”写経” すればコードになるんだろう？（・∀・）ﾆﾔﾆﾔ
書いてあるものを全くそのまま写す。
少しでも書き換えたり付け足したり削除したりしたら
本来の意味の（お経の）写経にはならないよね？
つまり何が言いたいのかというと
設計＝コードなのさ。
コーダーっての設計でできたコードを紙に印刷して、
はそのコードをコンピュータにそのまま入力するのが仕事。
> PGと呼ばれてる人の定義は？
> コーダの定義は？
遠い昔の話しさ。
昔はコンピュータがものすごく高価で
一人一台無いの当たり前、数時間単位で交代で使っていた。
だからといってコンピュータが使えない時間に遊んでいていいわけなくて
”紙”にコードを手書きしていた。そのコードを書くのがプログラマ。
プログラマだからといってタイピングが速いとは限らないよね。
そう、その紙に書かれたコードをコンピュータに高速で間違いなく入力する人がコーダー
今は、コードを紙に書くなんてことはしないので、コーダーというのは存在しなくなった。
もしコーダーがいる会社があったとしたら、そこのプログラマは手書きでもしてるのか？って
言いたくなっちゃうよ。
>辺を共有するハーフエッジが互いに同方向を向くかどうかを調べればよくないか？
その値を出すことは可能なのは解るよ。じゃあそれをどうやってコードに落として自動テストするの？
そこが問題だよ。もうひとつ聞くと、それは式が正しいかであって結果が正しいかは調べられないよね。
http://up3.viploader.net/pc/src/vlpc011111.png
本題でもないけど処理の内容が上手伝わってないようなので
何日持つのか解んないけど画像上げてみた。
左上の三角が辺のめぐり順が正しい場合。
右下の三角が辺のめぐり順が間違ってる場合。
右下の方は解りやすいように、分解度を下げ、
穴が開いた周辺の三角に色を塗っておいたよ。
三角形を描画する関数をスタブに置き換えて、三つの頂点を a, b, c として、
・描画済みの辺の集合に ab, bc, ca を追加
・描画済みの辺の集合に ba, cb, ac があればエラー
とするだけでしょ。全然テストしやすい部類に入ると思うけど。
・前者について
君の言う自動テストというのは、変数 xs を細分化後の三角形リストとして、
リスト内の全ての三角形において正しい順に頂点が並んでいる場合に
isValid (xs) が真となるような関数 isValid を作る事だよな？
ハーフエッジがどういうものかは既に分かっており、
それが有向グラフで表現できることも分かっているんだよな？
細分化後の三角形リストを元にハーフエッジを表現する有向グラフが作れれば、
その有向グラフの全ての辺を調べ、２つのノードを共有する２辺について、
それらが互いに逆向きになっているかどうかを調べることで、
全ての三角形が正しい方向を向いていることを調べられることは分かるよな？
（君の言う >>52 の方が正しければ、互いに同じ向きになっているかを調べる）
そのような方法で isValid 関数が作れることも分かるよな？
で君は「細分化後の三角形リストからハーフエッジを表現する有向グラフを作る方法」
結局のところこれが分からないから教えてほしいと言うことなのか？
式が正しければ結果は必ず正しいという前提で（信じて）行うのが「テスト」だ
これは分かってるか？
その「式」と「結果」には何が含まれると考えている？
当然、式には「細分化を計算する式」と「レンダリングを計算する式」が、
結果には「細分化された結果」と「レンダリングされた結果」が含まれるはずだが
どうも君は「細分化を計算する式」だけの正しさと、
「レンダリングされた結果」だけを結びつけて
「式が正しいかであって結果が正しいかは調べられない」と言っているように聞こえるが
つまり、レンダリングを計算する式の正しさを検証するテストについて考慮していない
>つまり、レンダリングを計算する式の正しさを検証するテストについて考慮していない
その通りだね。あくまでもレンダリング部分は正しいという前提で書いてるよ。
>「レンダリングされた結果」だけを結びつけて
>「式が正しいかであって結果が正しいかは調べられない」と言っているように聞こえる
これもその通り。そもそも>>43さんとの間に式というものに認識の齟齬があるのかも知れない。
今のところ、こちらとしては>>43さんのいう式は回転の向きの計算だと思ってます。
じゃSubdivision関数全体のテストをするにはどうするの？ってのが気になってます。
で、今のところSubdivisionのテスト結果は描画結果が正しいかで判断するしか
無いだろう、別の方法でもあるのかなーという風に思ってます。
あとは細分化した三角形の頂点座標が同じかどうかチェックすれば十分では？
結局のところ、何をテストしたいのかはっきりさせればいいのでは。
Subdivision関数を呼び出したときの描画内容をテストしたいのなら、
描画結果の確認をするだろうし、
Subdivision関数自体の動作をテストしたいのなら、描画APIを自前の
ものに入れ替えて、APIに渡される座標値などをチェックするだろうし。
> じゃSubdivision関数全体のテストをするにはどうするの？ってのが気になってます。
君は自分が提起した問題を自分で何か別のものにすり替えていないか？
あるいは本当は何をテストしたいのか、自分でも整理できていないのではないか？
>>38
> 正しい方向で巡らないと穴が開いたりすんだよね。
> こんなのどうやってテストすんだろ。
この通り、テストしたい事柄は「正しい方向で巡っているかどうか」だけだと思ってたが
つまり、三角形を構成する3つの頂点座標が正しい順でリストに入っているかどうか
これであれば >>66 の方法で正しいかどうかを必ずテストできる（効率云々は別の話）
テストしたいことが他にもあるのなら、>>70 の言うようにハッキリさせなさい
それともう一つ言っておくが、ある事柄をテストする場合は、
その事柄が「依存する」他の事柄について完全にバグが無い状態でテストすべきだ
（正しくは、バグが無いことを信じられる、前提にできる状態）
依存する他の事柄にバグがあれば、テスト結果が何によってもたらされたのか分らない
テスト結果を信用することができない
Subdivision関数全体というのが、
どのような場合にどのような結果が出る事を想定したテストの事か知らないが、
それを求めているということは、当然それが依存する他の事柄は全てテストできている
ということなのか
しかし私は、正しい方向で巡っているかどうかすらテストできていない状態で、
Subdivision関数全体とやらが正しくテストできるとは到底思えない
だから、今でもコーダーという職種が存在してるってば
Web業界に
Subdivision()が正しく動作しているかどうかの確認項目に、レンダラーに正しく情報を渡しているかどうかが
あるなら、それをチェックできるようにすべき。
上記のSubdivision()が何をしているのかわからないが、「座標を計算し、描画し、何らかの結果をboolで戻す」
関数だとしたら、それは責務が多すぎるのでリファクタリングしてテストしろと思う。
てすとしないんだろ
privateなんで正しいかどうかチェックできんわーと言ってるのと同じだな。
観測が必須なのに観測できないコードだからテストできないのなら、観測できるような
設計にしてからテストすればOK。なんも難しいことなんて無い。
そうですね。
テスト目的自体は、Subdivision関数が正しい結果をだすか否かを確認し、
この条件での実行は問題ないと証明することです。
別に何が原因でバグが発生したかはどうでもいいといえば、どうでもいいです。
描画関数についてですが、それ自体は、飽くまで結果の確認方法という位置づけです。
貼りつけたコード上では解りませんが、描画部分は仮想関数で、そもそも何を実装するのか
決まってません。確認方法の実装が描画以外の方法でも全く構いません。
1種類に限らず複数の確認方法でも構いません。ただ、確認方法の候補として
今のところ描画を持ち出してるだけです。
>>71
>>74
私が穴が開くって所を引きずったせいで、ややこしくさせてる感じがありますが。
穴が開くのは、「穴が開いたり」と書いたように、飽くまでコーディングミスで起こり得るバグの一例です。
他にもコーディングミスで三角形全体を囲む辺がでこぼこになったりというのもあります。
ただ、あくまでテストなので、正しいか正しくないか2択の結果が得られれば十分だと考えてます。
Subdivisionはとりあえず置いといて、
使ってる描画APIは頂点を共有する三角形を複数描画した時に
(うまく頂点を指定しないと)穴が開いたり、
辺がでこぼこになったりするものなのか？
上記の問いに対する答えがYesで、かつ正常に描画されることを確認したいのなら、
描画結果を保存して、理想的な描画結果と比べるしかないだろう。
塗りつぶしの処理自体は全く問題有りません。
自分が作った塗りつぶし処理を使う必要もありませんから、
出来合いのライブラリつかってもいいですし。
>描画結果を保存して、理想的な描画結果と比べるしかないだろう。
見比べるんじゃなくGood, Bad、 成否といった形で結果が欲しいんですが。
このスレの趣旨はテストの自動化だと思って今まで質問してきたつもりです。
全てのテスト条件の結果を一枚一枚見比べるというのは昔ながらの方法じゃないですか？
本来、描画する方法が正しければ、>>79 の言うように
画像比較「でも」正しく、かつ自動的に Good, Bad でテストできる
その方法を初めに >>43 で言ったはずだ
隣り合う三角形が共有する頂点の座標が同値の場合に、
１ピクセルも穴が開かない「普通の正しい」レンダリングエンジンを使っていれば、
>>43 や >>79 の画像比較「でも」問題なくできる
１ピクセルずつ元画像と比較すれば良いだけだ（プログラム的には至極簡単）
しかし君は、私たちには何故か理由は分らないが、
正しい順で頂点を巡っても穴が開く場合があると主張する
であれば、それはそのレンダリングエンジンに問題があるか、
あるいは共有する頂点の座標が同値でないという不適切な細分化処理をしているか、
このどちらかありえないと私は思う
だから >>79 や >>43 の画像比較でテストするという前提なら、
Subdivision のテストとレンダリングエンジンのテストは分けるべきだ
そして当然レンダリングエンジンのテストの方を先に考えるべき
それとは別の話として、１ピクセルずつでの画像比較ではあまりに処理時間がかかる
というのであれば、Subdivision の方のテストとしては >>66 の方法でテストできる
これも正しく、かつ自動的に Good, Bad でテストできる
私からは２つのテスト方法、画像比較とハーフエッジをの提案したが、
それで不満であれば私が提案できるテスト方法はもうない
（２つの方法の処理速度改良案、あるいは計算機科学的に正しさを証明する方法はあるが）
紛らわしいタイポをしてしまったので訂正する
> であれば、それはそのレンダリングエンジンに問題があるか、
> あるいは共有する頂点の座標が同値でないという不適切な細分化処理をしているか、
> このどちらかありえないと私は思う
このどちらか「しか」ありえないと私は思う
>１ピクセルずつ元画像と比較すれば良いだけだ（プログラム的には至極簡単）
ここに関しては異論はありませんよ。これしか方法が無いのかとも思いますが。
> これしか方法が無いのかとも思いますが
確認だが、これしか方法が無いと思うとはどういう意味だ？
画像比較でテストするならば、これしかという意味だよな
まさか、画像比較ではない >>66 の方法は無視するという意味ではないよな？
なんで、オブジェクトに自己内部テストを行う
publicなselftestメソッドを作ろうって話にならないの？
ユニットテストは外部からのテストをするものだから
って意見はわかるんだが、テストをするのが目的であって
外部からテストをすることにこだわる必要ないよね？
オブジェクト自身にprivateなメソッドのテストを行う
selftestメソッドを持たせてもいいと思うんだけど。
つまりオブジェクトには（自分自信の）テストコードが含まれてる。
> ユニットテストは外部からのテストをするものだから
> って意見はわかるんだが、テストをするのが目的であって
> 外部からテストをすることにこだわる必要ないよね？
１行目のテストは、インターフェース部分が正しいことを確認するテストですよね
２行目と３行のテストは何が正しいことを確認するテストを意味しているのでしょうか
関数を作る時、その関数になったら、小さい関数に分ける。
この時小さい関数は外部から呼ばれることはない。
（作った理由が長いだけだから）
そして長い処理全体を一気にテストするのではなく、
小さく分けた関数ごとにテストを行う。
小さく作って小さくテストしたほうが
バグもみつかりやすいし、修正も楽。
だがこの関数は外部に公開しないものであるため
外部からのテストは相応しくない。
なら内部からテストをすれば良い。
これでいいかい？
○ 関数を作る時、その関数が長くなったら、小さい関数に分ける。
自己チェックモードを備えているものがあるよね。
インターフェースのチェックではなく
自分自身が壊れていないかチェックする機能
つまり、内部でしか使わない関数の正しさをテストするために、
その様な関数をコールして値と結果の整合性をテストする処理が書かれた
publicなselftest関数を作れば、外部からそのselftest関数をコールしてテストできる
という意味でしょうか
それは、何か特別なテスト方法として提案するまでもなく、
必要があれば誰もが普通にやってることなので、
特に作ろうという大きな声が聞かれないだけではないでしょうか
（内部関数をユニットテストしたいと思ってるプログラマなら普通に思いつく）
あるいはもっと簡単に内部関数の中や、それを呼んでる関数内で、
比較演算と printf や assert などを使ってテストを済ませてしまう場合もあります
なぜなら、そもそも長いから小さく分けた程度の重みしかない関数だから
また、最近のオブジェクト指向言語ならば、
クラスのプライベートメンバへ外部からアクセスする手段が用意されているので、
それを使ったテストツールを作る事もできますし
（selftest 関数を作るより、こちらの方がテストターゲットのクラスを弄る必要がなくて良い）
そのような方法を使ってるのかどうかは知りませんが、
最近の VisualStodio はプライベートメンバをユニットテストする方法も提供されてますね
http://msdn.microsoft.com/en-us/library/bb385974.aspx
なので、publicなselftestメソッドを作ろうって話になる（盛り上がる）には、
今ひとつ方法論としてのインパクトに欠けるような気がします
これがいかんのよ。
プライベートはあくまでプライベート。プライベートは内部で仕様が変わる。
本来プライベートなのだから自由に変えていいはず。
そこを外部からテストするのはおかしく、内部からテストをするしかないはずなのだ。
で、なんでselftest関数なのかというと、
個々でばらばらで作るんじゃなくてselftestで統一されてれば
コードを書かずともあとはフレームワークやら何やらが
見つけて勝手にテストしてくれるようになるでしょ？
> これしか方法が無いのかとも思いますが。
だって、レンダリングがおかしくなる条件がはっきりしてないんだからしかたない。
これが「xxという条件のときに、レンダリング結果がおかしくなる」とわかっていれば
xxという条件が発生していないかどうかでチェックできるんだけど、一連の書き込み
からは、どうもその条件がはっきりしない(というか、はっきりさせたくない?)わけで。
拘束条件(不変表明)が守られているかどうかをチェックするためのI/Fを作って、
呼んでもらうようなことはよくやる。
どちらかというと、テストのためというより異常状態になったときに検知するための
Assertに近い使い方だけど。
プライベートがあくまでプライベートと言うなら
publicなselftest関数はあくまでパブリックじゃないの？
「これはselftest関数だから
テストフレームワーク以外から呼ばないでね てへぺろ」
とかドキュメントにでも書いとけば許されるのか？
それって、selftest関数自体は外部からテストするような格好でコールされるんですよね
単にselftestという名前を統一的に決めておいて、
テストツールから自動的にこの関数がテスト目的で呼ばれるようにするだけのこと？
”誰が”テストをするかを明確にするためのもの。
コードを有るべき場所に置く。
自分のことは自分にしかわからない。
そこがあるべき場所。
selftest関数の意義はわかりましたが、
仕組みや、できる事できない事がまだ今一よく分りません
例えばその小分けした関数が、
それをメンバ持つクラスのプライベートメンバ変数にアクセスしている場合は、
selftest関数を使ってどうやってテストするのでしょうか？
小分けした関数がそのようなタイプだった場合は、
ある環境下でコールされることを想定しているという依存性がありますよね
この関数は内部関数なので、普通のユニットテストをしている状況では、
本来はそのような内部の依存性は全く問題にならないものです
（インターフェース部分の結果さえ正しければ内部は問わないから）
しかし、そのようなタイプの関数をselftest関数でテストするのなら、
同じ環境をわざわざ作る（再現する）必要があると思うのですが、どうでしょうか
他にも、こういうタイプの関数はselftest関数では難しいとか、
こういうタイプの関数ならselftest関数でテストする利点があるとか、
何かあるでしょうか
> しかし君は、私たちには何故か理由は分らないが、
> 正しい順で頂点を巡っても穴が開く場合があると主張する
このスレ的には、そこはどうでもいいってことにいい加減気づいてください。
>>76
> ただ、あくまでテストなので、正しいか正しくないか2択の結果が得られれば十分だと考えてます。
戻り値boolの意味は、「正しい」「正しくない」で、それをテストしたいのだったら、それぞれのテストケースを
与えて戻り値をチェックすればいいだけのことだろ。
何で穴が開くだの、描画結果がだのという話が出てくるんだ。
100〜のスレッドの続きを読む