優秀なプログラマーは運が悪い

ような気がしないでもない。

まぁ何かそんな具体的な話があったというわけでもなく。
テストのお話です。

テストってのは、もちろんソフトウェアがちゃんと動くかのテストです。

大体趣味で書いてる時って言うのは、テキトーにコードを書いてはキリのいいところでコンパイルして、実行してみる感じでやってます。
テストドライバとか書いちゃったりするのは、どっちかってーとお足の出るようなプログラミングのときで、普段は「めんどくせ」ってなることが多かったり。でも勉強量として多いのは普段のプログラミングなんですよね･･色々無茶をやるから。

さてそんなテストですが、ブラックボックステストとホワイトボックステストなんてものがあったりするのは、確か中学の技術家庭科の教科書にも載っていたことです。

カバレッジ的な見方をすると、ブラックボックステストは不定。ホワイトボックステストは条件分岐カバレッジが100％になるようにテストするわけです（とはいえ、わざわざ発生させるのが面倒くさい例外は省いたりしないでもないですが）。

しかしここで運が悪いプログラマは更なる学習の機会を得るのであった･･！

JUGEMテーマ：コンピュータ

つまり、分岐のカバレッジではなく、状態のカバレッジのお話です。

いわゆるコンピューターが、有限状態オートマトンの一種であり、決定的な動作をする以上、状態カバレッジを100％にすることは、論理的には可能です。たとえばあるプログラムで使われる変数や、入力のパターンを全通りチェックするわけです。

とはいえこれは1バイトの変数を一個導入しただけで、256個のテストケースが生まれるわけです。2個なら65536個。とても現実的な値ではありません。でも運の悪いプログラマはここでその特殊能力を発揮します。

つまりこんな場合があるのです。

a = b / c;

のようなコードがあり、bとcは0~255の乱数（一様分布）としましょう。
何が問題でしょうか。

そうです、cが0になった時に、ゼロ割りが発生してしまいます。

じゃあ一回このコードが走ったときにそれに気づく確率は？　前提条件から考えて、1/256ですね。
運が悪いプログラマはデバッグが早い！　とか、なんとか今日も再現性の無い（低い）バグに悩まされながら考えていました。はい。

あー、でも超人的に運が良かったら、死ぬまでワーストケースにご対面しないかもな。それはそれで。