チームでの業務アプリケーション開発経験、そろそろ右も左もわからないイタイケナ子羊さんも駆り出される季節ですね。まぁここにいらっしゃる方はどちらかというと羊飼いや狼さんな立場の方々が多く（笑）けれど、ここは基本に立ち返ってみるのもどうよ？というわけで、ちょいとこんな戯言など書いてみたり……
テストって一口にいうけど、たくさんの種類があります。システムが完成するまでの間、大まかな流れだと、作られた部品のチェック→部品を組み立てて動かすチェック→全体を動かすチェック→納品前にお客さんも立ち会ってチェック→納品、というわけでプログラム開発も車を組み立てて売るのも工程という視点から見ると対して変わらなかったりするんです。そんな中、最初だし、作られた部品のチェック、それも「作るのはじめてなんですけど」的立ち位置から書いてみたいとおもいますです。
単体テスト（UnitTest UT）ってなぁに？
まぁそのとおり、部品のテスト、です。だいたいは、以下のことを実際にプログラムを動かして確認します
- 何をどう入力したら、何がどこに出てくるのか
- プログラムに書き込んだ分岐や繰り返しの処理を実行できているか
え？これだけ？と思うでしょうが、レベル０で突き詰めてしまえば注意すべきは上の二つです。このポイントを押さえて「何をどう操作して、どう結果を確認するのか。何をもって正しいとするのか」をあらかじめ準備する事でいきなり完璧ではないにせよ、漏れの少ないテスト準備をすることが出来るようになります。
何をどう入力したら、何がどこに出てくるのか
入れるものがファイルだったり画面だったりデータベースだったりとか、出すものがファイルだったりデータベースだったり画面だったりとかするんですが、基本はあくまでも「何を入力したら何が出てきたか」、それだけです。テストを始める前に、「何を入れるのか」を決めて「それを入れると何が出てくる」かをメモなり表なりにまとめておきます。決められたテスト仕様書があるのならそれにあわせて書きましょう。どうもうまくまとめられないな、と思ったら自分がチェックしやすいように別紙として作成し、添付できるようにしておくと楽です。
さて、そこでちょっと考えてみます。「これをいれるとこれがでてくる」「こうなるのが正しい」という根拠はどこから来るでしょう？ 大体はプログラムを作った仕様書にあるはずです。仕様書を作った人が別にいらっしゃる場合には、この段階で表を見てもらい、確実に仕様書に沿った入力と出力になっているかどうかを確認してもらっておくとテストやり直しの手間が少し減るかも、ですよ。先輩は積極的に活用しましょう（笑）