最近Python勉強してます。
テストユニットの書き方を勉強がてら
ふと思ったことを殴り書き。

。。。

テストの書き方はたくさんあるけれど、
知らない人は知らないし、知っている人は
xUnitとか良い感じのフレームワークでテストコードを書くか、デバッガを用いて確認するか
ログとって解析しているんではなかろうか。


ゲーム業界はよく知らないけれど、
たしか単体テスト用のコードはあまり書かないと
掲示板で見たような？ 気がする。（うる覚え
まぁ、頻繁に大きく仕様変更が入る業界ではあまり効果がないかもしれないけれど
テスト自体を全くしないということはありえないと思うので
なんだかんだ言ってブラックボックスなテストコードは結構書いて
使いまわしているんではないかなぁと予想してみる。
はたまた、やはり1つの関数(メソッド)の機能がでかいので
結合検査で実施してログ解析とか。
はたまた、正確な値よりも見た目が上手くいっていれば良い方針とか。
もしくは、違う場所(市場デバッグ)で品質を確保しているとか。
予想はつきない。


さてさて、そこはおいといて実際問題。単体テスト(デバッグ)するうえで意識する点は
以下のように考える人は多いのではないでしょうか。
・代表値で正常に動作するか
・オーバーフロー、アンダーフロー、ガードはかかっているか
・境界値は大丈夫か(> or >= のミスなど)
・0を突っ込んだときも正常に動作するか(0で割り算していないか等)

ブラックボックスだろうとホワイトボックスだろうと
「基本的」なスタンスは同じかなぁと思います。


例えば、閏年を求める仕様が以下だとする
西暦年が4で割り切れる年は閏年
ただし、西暦年が100で割り切れる年は平年
ただし、西暦年が400で割り切れる年は閏年
入力は0～3000年までと保障されている

とした場合、

代表値
0 → 閏年
2000 → 閏年
2008 → 閏年
2009 → 平年

境界値
3 → 平年
4 → 閏年
5 → 平年
96 → 閏年
99 → 平年
100 → 平年
101 → 平年
104 → 閏年
399 → 平年
400 → 閏年
401 → 平年


てな感じのパターンを取っておくと最低限のテストはできているんじゃないかなと思う。
後は、どこで腹を括るかになってくると思います。

さて、本当に思いついたことを書いている感じ。。。
眠いorz

nodchipさんの本(同人誌)によると、テストケースは
「サンプルテストケース」「最小テストケース」「最大テストケース」
「コーナーケース」「ランダムテストケース」「ビューティフルテストケース」を用意するのがいいらしいです。

サンプルテストケース…作りたいプログラムの説明についているサンプル
この場合の例：2000,2008,2009,2014

最小テストケース…使用上許される最小のテストケース
この場合の例：0

最大テストケース…使用上許される最大のテストケース
この場合の例：3000

コーナーケース…他のケースに対して正しい出力をするプログラムでも、正しい出力ができないようなケース
この場合の例：「境界値」

ランダムテストケース…乱数で作ったテストケース
この場合の例：659,2446,1795,2262,993

ビューティフルテストケース…ネタ
この場合の例：1111,2222,666,777,1945,1984

単体テストはやったことないですが、数字に関係した検査だと2の階乗の値ってポイントになると思います。

ゲーム開発の場合、
そもそも（外部、内部、ＰＧ）設計書もまともに書かないので、
単体テストも結合テストもテストケースの作りようが無いというのと、
ソースが読めないテスト担当者が、現時点で完成しているプログラムを実際プレイするのが
ゲーム業界のテストと言われています。
（全ての企業の内情は知らないのでひとくくり出来ませんが）


ホワイトボックステストは網羅率を出すテストですが、
それは結局ソースレビューをテストの視点で行っているだけかなと思います。
そして時間がかかります。
私が前にSEとして務めていた時は、
単体はほとんどブラックボックスだけで済ませてました。
結合テストに一番労力をかける風習で、
ほとんどのバグはそこで見つける、という感じだったからだと思います。

みけCAT さんが書きました:nodchipさんの本(同人誌)によると、テストケースは
「サンプルテストケース」「最小テストケース」「最大テストケース」
「コーナーケース」「ランダムテストケース」「ビューティフルテストケース」を用意するのがいいらしいです。

なるほどです。
例も参考になります。

ビューティフルテストは初めて聞いたのでググッてみたら
オライリー本にヒットしたのでネタではなくオタだったのですね。

こじこじ さんが書きました:単体テストはやったことないですが、数字に関係した検査だと2の階乗の値ってポイントになると思います。

理由はなんでしょうか？
※なんとなくでも良いですし、単純に興味本位で聞いてます。

FUNK さんが書きました:ゲーム開発の場合、
そもそも（外部、内部、ＰＧ）設計書もまともに書かないので、
単体テストも結合テストもテストケースの作りようが無いというのと、
ソースが読めないテスト担当者が、現時点で完成しているプログラムを実際プレイするのが
ゲーム業界のテストと言われています。
（全ての企業の内情は知らないのでひとくくり出来ませんが）

ホワイトボックステストは網羅率を出すテストですが、
それは結局ソースレビューをテストの視点で行っているだけかなと思います。
そして時間がかかります。
私が前にSEとして務めていた時は、
単体はほとんどブラックボックスだけで済ませてました。
結合テストに一番労力をかける風習で、
ほとんどのバグはそこで見つける、という感じだったからだと思います。

まぁ、イメージですがゲーム開発業界は
仕様が大きく変わることがざらで、かつスピーディーな要求が求められているのかなと思っています。
そうなると必然的に結合テストやエンドユーザに近い環境のテストが一番効率的になる感じですかね。
細部見にくいけれど、影響などは見やすいですしね。

ゲーム業界の話を聞けて面白いなぁと思いました。

トントン さんが書きました:

こじこじ さんが書きました:単体テストはやったことないですが、数字に関係した検査だと2の階乗の値ってポイントになると思います。

理由はなんでしょうか？
※なんとなくでも良いですし、単純に興味本位で聞いてます。

割とよく使われる数字だと思ったからです。
例えば、256個の要素のメモリーを確保するときなどです。

企業のシステム開発も組み込みもハード含めたものですからね。

ゲームはマルチプラットフォームでプラットフォームごとに異なる厳しい制約があったりします。
クロス開発だとデバッガひとりひとりに開発機を割り当てるなんて予算的にも物理的にも無理があります。
PCでテストできる部分なんてほんとにコアな部分だけですし。
ゲーム開発でテストケースを作れないのは設計の問題ではないと思います。

こじこじ さんが書きました:

トントン さんが書きました:

こじこじ さんが書きました:単体テストはやったことないですが、数字に関係した検査だと2の階乗の値ってポイントになると思います。

理由はなんでしょうか？
※なんとなくでも良いですし、単純に興味本位で聞いてます。

割とよく使われる数字だと思ったからです。
例えば、256個の要素のメモリーを確保するときなどです。

なるほど、よく使われるものだからこそポイントですね。
ありがとうございます。

ISLe さんが書きました:企業のシステム開発も組み込みもハード含めたものですからね。

ゲームはマルチプラットフォームでプラットフォームごとに異なる厳しい制約があったりします。
クロス開発だとデバッガひとりひとりに開発機を割り当てるなんて予算的にも物理的にも無理があります。
PCでテストできる部分なんてほんとにコアな部分だけですし。
ゲーム開発でテストケースを作れないのは設計の問題ではないと思います。

ハード関連はわかりませんが(というかゲーム業界わかっていない人)、
APL開発者だとハードに積む前にスタブとか作っておいて(作ってあり)
それで動かせるイメージでいたんですけどね。

＞PCでテストできる部分なんてほんとにコアな部分だけ
というのが肝っぽいですね。
それ以外は、そもそもハードに対して命令してる感じなんですかね。
だとするとハードが提供されている環境であれば
やはり可能になってくるような気がしますけど
そうそう、簡単に手にはいるものではないものが多いと思われるので確かに不可能になってきますね。