最近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

組み込みまれているチップの違いで、特定のメーカーの特定のロットの製品にだけ依存する制限があったりします。
家庭用ゲーム機でロットが変わって動かなくなったソフトをメディア交換やパッチで対応するようなことがありますよね。
もちろんプログラムは仕様書どおりに作ってあって潜在的なバグがあったわけでもなく開発機では問題なく動いていたりするのです。

検証に必要なハードをすべて自前で用意するよりも、既にそれらを準備している専門の会社にデバッグを発注するほうがはるかに安上がりになります。
お金のない会社は社員が個人的に購入したハードを掻き集めて検証するのですがそれでも再現しないことがあったりします。

ハードに命令出してハードがその通りに動くというのは、マイクロソフトのような大きな力を持ったソフトウェア会社がハードを支配する関係にある場合だけです。
端末を売る業界ではハード会社のほうが力が強いですし、いろんな会社がしのぎを削っているので、それを追いかけてプログラムを作ることになります。

ISLe さんが書きました:組み込みまれているチップの違いで、特定のメーカーの特定のロットの製品にだけ依存する制限があったりします。
家庭用ゲーム機でロットが変わって動かなくなったソフトをメディア交換やパッチで対応するようなことがありますよね。
もちろんプログラムは仕様書どおりに作ってあって潜在的なバグがあったわけでもなく開発機では問題なく動いていたりするのです。

検証に必要なハードをすべて自前で用意するよりも、既にそれらを準備している専門の会社にデバッグを発注するほうがはるかに安上がりになります。
お金のない会社は社員が個人的に購入したハードを掻き集めて検証するのですがそれでも再現しないことがあったりします。

ハードに命令出してハードがその通りに動くというのは、マイクロソフトのような大きな力を持ったソフトウェア会社がハードを支配する関係にある場合だけです。
端末を売る業界ではハード会社のほうが力が強いですし、いろんな会社がしのぎを削っているので、それを追いかけてプログラムを作ることになります。

ISLeさんは広い視野で話されていた感じですね。
(勘違いしていました)

ソフト的に問題なく、ハード側で問題があってもソフト側で修正することは
よくある話だと思います。(正確にはハード側に問題が無いからソフト側で合わせこむだと思いますが)
また、コストを考慮して外部に委託するもの納得です。

＞お金のない会社は社員が個人的に購入したハードを掻き集めて検証するのですが
こういうこともやはりあるのですね。
やっている方は堪ったもんじゃないと思いますが第3者視点からは面白いなぁと思いました。

ハード側にまったく問題ないなんてことがあるはずないじゃないですか。

ISLe さんが書きました:ハード側にまったく問題ないなんてことがあるはずないじゃないですか。

あ、ごめんなさい。
書き方ミスしたっぽいですね。

ハードに回路が組み込まれていなかったとか
端子のつなげ方を間違えたからソフト側で修正してくれとか=仕様にする
という感覚があったので
「正確にはハード側に問題が無いからソフト側で合わせこむだと思いますが」
と書きました。

まぁ、物理的なものなのでよくあるとは思っています。

トントン さんが書きました:まぁ、物理的なものなのでよくあるとは思っています。

これは、開発中にはよくある的な感じで書かれているように読めますが。

既に出荷されているハード側のバグを回避してソフトウェアを作るということは日常的に行われています。
アプリの開発の場合、ハード側というとファームウェアも含みます。

出荷時には発見されていないバグの場合、一般ユーザーがふつうに使っていて問題になるような致命的なものでない限り放置されます。
バグを回避するように作られたアプリがリリースされるので、ハード側のバグが一般ユーザーの目に触れることは滅多にありません。
大衆向け製品の場合、1ロットで何千何万という単位の製品が作られるわけですから、バグが見付かるたびに回収なんてできるわけないですからね。


わたしが経験した中では、ガラケーアプリで、ある特定のメーカーの特定の機種の初期ロットでだけアプリを起動すると端末が再起動を起こすという現象がありました。
アプリはその機種が発売される前からリリースされていたもので、それまで問題はありませんでした。
同じサイトで公開されているアプリが何百とある中で症状が出たのはひとつだけでした。

調べてみるとJavaのclassファイルをロードする瞬間に落ちていることが分かったのですが、コードを1行移動してclassファイルの中身がちょっと変化するだけ(もちろん実行する内容は何も変化しない)で発生しなくなりました。
しかしどんなclassファイルだと落ちるのかということまでは特定できませんでした。

端末に搭載されたJavaの仮想マシンに問題があることは明らかでしたがメーカーに問い合わせてもまったく返事がなく、公開されているアプリは症状が出ないファイルに差し替えたものに更新するというだけの対処をしました。
同時期にアプリの公開を一時停止しているサイトが他にもあったので、同じ症状に見舞われたのかもしれません。

しばらくして、その機種の新しいロットが出たということで、同僚が更新前のアプリを動かしてみたところ問題なく動いたそうです。
けっきょく端末メーカーからその件に関するアナウンスは一切ありません。


書いているあいだに思いましたが、こういうことがあったときに怒りを覚えるのはその現場に居合わせたアプリ開発者だけなんですよね。
一般ユーザーは互換性のあるはずの新機種でアプリが動かなかったとしても、アプリのせいだと思いますしね。

そうですね。トントンさんは正しい。

ISLe さんが書きました:

トントン さんが書きました:まぁ、物理的なものなのでよくあるとは思っています。

これは、開発中にはよくある的な感じで書かれているように読めますが。

ご指摘ありがとうございます。
確かに、そう解釈できますね。訂正します。

ISLe さんが書きました: 出荷時には発見されていないバグの場合、一般ユーザーがふつうに使っていて問題になるような致命的なものでない限り放置されます。
バグを回避するように作られたアプリがリリースされるので、ハード側のバグが一般ユーザーの目に触れることは滅多にありません。
大衆向け製品の場合、1ロットで何千何万という単位の製品が作られるわけですから、バグが見付かるたびに回収なんてできるわけないですからね。

＞1ロットで何千何万という単位
一度ラインに流れたらバグがでないこと祈るばかりですね。
車だと即リコールですけどね。まぁ、ジャンルも違いますし数も違いますけどね。

ISLe さんが書きました: わたしが経験した中では、ガラケーアプリで、ある特定のメーカーの特定の機種の初期ロットでだけアプリを起動すると端末が再起動を起こすという現象がありました。
アプリはその機種が発売される前からリリースされていたもので、それまで問題はありませんでした。
同じサイトで公開されているアプリが何百とある中で症状が出たのはひとつだけでした。

調べてみるとJavaのclassファイルをロードする瞬間に落ちていることが分かったのですが、コードを1行移動してclassファイルの中身がちょっと変化するだけ(もちろん実行する内容は何も変化しない)で発生しなくなりました。
しかしどんなclassファイルだと落ちるのかということまでは特定できませんでした。

端末に搭載されたJavaの仮想マシンに問題があることは明らかでしたがメーカーに問い合わせてもまったく返事がなく、公開されているアプリは症状が出ないファイルに差し替えたものに更新するというだけの対処をしました。
同時期にアプリの公開を一時停止しているサイトが他にもあったので、同じ症状に見舞われたのかもしれません。

しばらくして、その機種の新しいロットが出たということで、同僚が更新前のアプリを動かしてみたところ問題なく動いたそうです。
けっきょく端末メーカーからその件に関するアナウンスは一切ありません。

それは、なんと言うか「言葉にできない」ですね。
メーカーに問い合わせても、返答がないときはつらいですね。
また、原因も不明なまま終わるのはつらいですね。一番腹が立つパターンだと思います。

ISLe さんが書きました: 書いているあいだに思いましたが、こういうことがあったときに怒りを覚えるのはその現場に居合わせたアプリ開発者だけなんですよね。
一般ユーザーは互換性のあるはずの新機種でアプリが動かなかったとしても、アプリのせいだと思いますしね。

そうですね。トントンさんは正しい。

＞トントンさんは正しい。
正しいかはわかりませんけどね。(実は皮肉という落ちとか＞＜)

ユーザーが操作系においてはアプリ側、物理的に影響があるもの(熱とか音とか)はハード側
だと思うのは仕方ないことなんでしょうね。
ユーザーにとってはどっちがどうとか関係ないですし。

しかし、自分が思っていた以上に
ハードが絡んでくると難易度が一気に上がりますね。。。
元々はテストの話もハード側のことは考慮したことではなかったですからね。

ハード側は問題を認めず、アプリ開発者はそれに従うしかない。
なので「正確にはハード側に問題が無いからソフト側で合わせこむ」は正しいということです。
現場の開発者の心構えとして、ですね。
納得はできないですけど。