気が付けば、東京ゲームショウに行ってからもう１週間が過ぎてました。
月日の流れは、なかなかの超特急です
もうちょいブレーキを踏んで欲しいと思う今日この頃。
こんにちは、ハラです。
ここ最近、ちょっとしたツールを作っていた絡みもあり、
テストについて少し書いてみたいと思います
１つの例として、下のような流れで処理や作業が行われるケースで
考えたいと思います
．データ作成＆コンバート
．プログラムがコンバートされたデータを読み込む
．読み込んだデータを使って色々な計算を行う
．計算結果を使って描画する
ちなみに、私がプログラムを始めた頃（懐かしの学生時代・・・）は、
どんな時でも、全てが出来上がった後にまとめてテストすれば良いと思っていました
この例なら、の段階で正しく描画されていれば大丈夫だろう、と。
今の私には、この考え方だと２つの問題がある気がします。
１つ目は、テストで不具合が見つかった際、～のどの段階に原因があるのか、
すぐに見つからない事
２つ目は、～の段階で複数の問題があり、その影響で結果的にが正しく動いてしまい、
不具合を見つけられない可能性がある事
１つ目の問題は、原因を見つけるために時間が多くかかってしまう、
というものなので、そこまで致命的ではないかもしれません。
（急いでいる時は、大きな問題になりそうですが……）
２つ目の問題は、致命的になる可能性を秘めています
後々になって問題が表面化する可能性が残るからです。
表面化するのが、作品を志望する会社に提出した後、
実際に見て貰うタイミングだったとしたら……
と、想像するとちょっと怖くなってきませんか？
最も確実な対策としては、～の全ての段階で
それぞれテストを行う事ですよね。
正しくデータが読み込まれているか？正しく描画が行われているか？など、
全ての段階でテストすれば、不具合が隠れてしまう可能性が最も低くなります。
ただ、最も確実ですが、最も手間がかかる事にもなってしまいます。
時間が限られている時は、もう少し手間を省きたい所です
となら、の段階でテストをすればデータの不具合は見つけられるはず。
データの正しさが保証されれば、とをまとめてテストしても不具合を見つけられるはず。
と、実際の処理に合わせて、行うテストを吟味していけば、
より良いテスト方法が見つけられるかもしれませんね
提出する作品の質を高める時間も大切ですが、正しく動作するかをテストする時間も大切です。
そして、使える時間には限りがあります
十分なテストを行いたいが、必要な時間を出来る限り減らしたい……
作品を作る段階からどのようなテストを行えば確実かを、多少意識しておくと良いのかもしれませんね