レベル０
http://blogs.wankuma.com/esten/archive/2007/06/18/81072.aspx
http://blogs.wankuma.com/esten/archive/2007/06/19/81308.aspx
ちょっと間が開いたのですが、前回の続き
「単体テストは全てのプログラムコードが処理されたことを証明し、書いていないプログラムコードの処理によって起きうる結果についても検証するテストである」というお話をしました。つまり、書いていないプログラムコード≒例外処理、ということが言いたかった前述だったのですが、先輩方のプログラムコードから単体テストを任される場合、ほとんどの場合「これら例外処理がプログラムコードに含まれている」ことが多いことに気づくと思います。例外処理を意識したプログラムコードが書けるかどうかも、プログラムスキルの一つといっても過言ではありません。レベル０でお話したとおり、「全てのプログラムコードの処理を確認する」単体テストを行えば必然的にこれら例外処理のロジックも通らなくてはならないのですから、例外処理を意識したプログラムは、テストを依頼する場合にテストする側が読み取らなくてはならない「書いていないプログラムコードの動作」について考慮する範囲が狭くなり、テストの難易度も下がる、と良い事づくしですね。
と、ちょっと話はそれましたが（汗）、レベル１の最後として、例外処理のテストについてもう少し突っ込んでみましょう。
いかに例外処理を発生させるのか
VisualStadio等のコードデバッグを可能とするツールの場合、イミディエイトを使うと簡単に実現できます。テスト直前のロジックでブレークポイントを設定し、止めた後に、判定の変数の中身を変更してしまうもしくは次の処理ロジックラインを目的の処理まで変更する、ことができるからです。また、UNIX、AIX等で使用されるDBXも同じく変数の中身の変更（assign コマンド）を行うことで擬似的に処理例外を起こす事ができます。
変数の中身の変更は、NULL値を設定、もしくはアドレスをNULL値に設定、とするとほとんどの場合例外処理を発生させることになるはずです。
例外発生時の処理結果保存
さて、そうやって何とか発生させたエラーです、確実に証拠を取りましょう。ダイアログが表示される場合にはダイアログをキャプチャーしてしまうのが最も手っ取り早く確実です。「ALT」＋「PrintScreen」キーを同時押しすると、現在、最前面にあるダイアログだけが画像データとしてクリップボードに送られます。ペイント等で貼り付けて確実に残しましょう。画面上にエラーが表示される場合のみの場合も同様です。大切なのは「こうなった時にはこういう結果が出る」ということを確実に証拠として残しておく、ということです。習慣づけておくと良いですよ。
今度、レベル２はその単体テストで作成しておくべき「テスト仕様書」と「テスト結果」について、ちょこっと話……してもいいかな？＜おい