- 例えばPONGのテストを書く場合ってさ
バーがボールを弾くことを確かめるにはどんなコードを書けばいいのさ - 何を言ってるんだろう
- なるべく純関数で作ってスナップショットテストを作ると楽
- ぜんぶおしえて
- パッと思いついた方法だと
バーとボールの状態を予め決めておいて、さらに事前にその状態からボールがバーに弾かれた後の状態も求めておいて
実際にプログラムを動かしてみてその結果と事前に求めた結果が同じかどうか比較する
同じならテストは通る、違うならエラー
でもこんなのバーとボールの状態を全通りテストする訳にはいかないし気持ち悪いよな - 簡単だよ
まずはテスト用の変数を作る
次にバーに接触した時にその変数に必要なデータを代入させる
例えば、接触しましたよ。角度はどれくらいでした。スピードはどれくらいでした。
こんな感じ - >>6-7じゃないの？
テストケースが無数にあるなら全部じゃなくてそれなりの数用意してこんだけやれば充分ですって言っちゃえばいいじゃん - バーと弾との当たり判定は作っていると思う
そこに当たった時にテスト用の変数に代入したらいいのさ
ちなみにテスト用の変数は構造体またはクラスで作るといいよ - 角度とスピードが分かってもそれが意図した通りに弾いてるのかが分からないといけないんだよね
やっぱり目視でそれっぽく動いているということを確認するしかないんだろうか - ああああ分からないわよおおおおおお
ゲームはテスト書くのが難しいのかなあああああああ
だからテスターたくさん雇って物量戦術で通すのかなああああああああああ - それも簡単だよ
テストをしたらいい
意図的に、ボールの出現場所、ボールの速さ、角度を設定して
チートみたいな感じにバーにわざとあてるテストをする
まあこれにも限界があって、ゲームプログラマの考える範囲でしかテストが出来ない
そして必ずといっていいくらいバグは存在する - 2Dのブロック崩しなら
全通りチェックしてもいいんじゃね - なんで人の話聞かないのに質問するの？
- そういうもんなの？
- >>15
そういうものなの。全通り試さなくて良い。
その代わり、何で試すかは考える必要があるし、つまり経験と勘とセンスが必要になる。
端、端の隣、反射する角度が変わる直前、変わる直後、ど真ん中、とか何とか。 - おちんぽだな
- ここらへんバグりやすそうだなってところに目星をつけて試すわけか
- どういうゲームでどういうバグを心配してるのか書け
- 昔クソみたいな自作テストフレームワーク作って既存フレームワーク汚い言葉でコケにしてた奴いたの思い出した
- まあ現実にはテスターっていうより
企画とかにやらせて
バグ見つけてくれーって感じだけど - しかもこれがやっかいで
複雑になればなるだけわけわからんバグが出て来る
このバグの解消がゲームプログラマーやってて一番頭痛くなる
動くには動くけど、何故かバグが出るって状態になる - こういう要領を得ない文を連投してもっと要領を得ない文章にする香具師は、
矛盾とか不整合とかを含んだプログラムを書くんだろうな、と思ってしまう。
複雑になればなるほどプログラミングには文系能力が求められる。 - >>24
どうなんだろうな
どちらかというとゲームプログラミングは理系に感じる
何故それが動くのか？何故その条件式なのか？みたいなのを完全理解しないと
何でここでバグが出るのか？ってのが理解出来ない - >>26
ゲームだろうが業務だろうが論理の積み重ね
論理は理系でも文系でもない
文理に対する認識が誤ってる - >>24
数式だってシンプルなほど優れてる
分離関係なく物事の捉え方の問題だと思う - まずは何事もシンプルにしろ
シンプルの積み重ねはバグりにくいしテストしやすい - テストコードでできる範囲はホワイトボックス前提で関数単位でテストするユニットテストだろ
それ以上のテスト自動化だと普通のテストコードではなく何かのフレームワークなり使わんと無理よ - ＞シンプルの積み重ねはバグりにくい
ダウト単体がシンプルであることと、合成が複雑であることとは相反しない。
逆にシンプルにし過ぎると、複雑に組み合わせないと使い物にならなくなる。
プログラミングで2Dゲームのテスト書きたいんだけど
VIP
コメント