前回 レベル０
http://blogs.wankuma.com/esten/archive/2007/06/18/81072.aspx
http://blogs.wankuma.com/esten/archive/2007/06/19/81308.aspx
さて、前回レベル０では、「単体テストは全てのプログラムコードが処理されたことを証明するテスト」とお話したと思います。今度はそれにもうちょっとプラス、「単体テストは全てのプログラムコードが処理されたことを証明し、書いていないプログラムコードの処理によって起きうる結果についても検証するテストである」というお話をします。
「書いていないプログラムコードって何？」
書いてないのに実行できるわけないじゃん！ええ、そのとおり。「書いていない」ことによって「起きうる事」をテストする、つまりは「予想外」をテストする、ということです。ポイントは大きく分けてまぁ、簡単に、以下のリストのようなカンジ。
ファイル入出力
入力ファイルが存在しない時
入力ファイルが既に誰かが使用している時
入力ファイルのデータ件数が０件の時
書き込みファイルのパス先が存在しなかった時
書き込みファイル名がOSの基準にあっていない時
書き込みファイルを誰かが使用している時
書き込みファイルのデータ件数が０件の時
データベース処理
接続失敗の時
SELECT処理で対象レコードが０件の時
SELECT処理で対象列データがNULLの時
更新削除処理で対象レコードが既に削除済だった時
デッドロックの時
処理途中でサーバーに異常が起きた時
画面処理
いきなりOSから強制終了される時
すでにそのアプリケーションが起動されていた時
これだけ？というか、まぁこれらはほんの一部。他にも色々とあるでしょうけれど、設計者もある程度の「予想外」は想定していると思うので、それ以外で、案外と気がつかないものを抜粋してみました。単体テストではこれら「予想外」についても「動かした結果こうなった」という証拠を残しておくことを薦めます。もちろん、レベル０で話したとおり、「こうやったらこうなった」という想定結果を準備しての実行ですから、本当に「こうなること」が正しいのか、心配なら識者や上司、リーダーさんに聞いておくとより安心ですね。
つまり、全ての処理ロジックを確認し、ロジック外、つまり例外処理についても考慮する単体テストを多くこなす事は、必要なプログラムコード、判りやすく安定したプログラムコードの書き方のコツをつかめるようにする第一歩です。私がまず新人さんにしてもらう作業はいつも、すでにコンパイル済でまだ単体の上がっていないプログラムのテストです。プログラムソースを読み、仕様書を書くこと、テストプランを練ることから始めてもらう事で、システムについて理解する手がかりを掴んでもらっています。そんな時、さっきのリストにあったような予想外の項目について「ここはどういう結果になればよいですか？」と確認してくれる人がいたりすると「むむっ、こやつできるな」とニヤリとしてみたり（笑）