プログラミングの完了後に行う単体テスト。
単体テストはプログラムを書いたことのある人なら誰しもが経験をしたことのあるテストだろう。
しかしながら、
・どんな観点でテストをすればいいの？
・エビデンスは取ったほうがいいの？
といった悩みを抱いたこともあるはずだ。
そこで今回は単体テストの基本的な知識を記載してみた。
単体テストの目的
単体テストの目的は、プログラムを1本ずつ個別に実行し、不具合（ロジックのミス）を取り除くことである。
一般的には、ロジックの条件分岐を網羅するテストを行うため、結合テストや総合テストなどの他のテスト工程と比較しても、圧倒的にテストケースが多くなる。
もう少し厳密に言うと、単体テストではロジックの最小単位（クラスやモジュール）のテストであるため、例えば画面のような複数のクラスで構成されるような場合は、Eclipse（Junit）等の開発ツールを用いてクラス毎にデータの動きを確認していく。（最初は複数クラスを結合したテストは行わない）
複数クラスを結合した画面表示を確認するのは、最小単位のテストを終えた後の機能単体テスト（正しくはソフトウェア結合テスト）であり、ここで複数クラス間のインターフェースを検証する。
ややこしい話だが、重要なポイントなので補足しておこうと思う。
プロジェクトのテスト工程は下記のような流れで行われる。
↓
ソフトウェア結合テスト（画面単体のテスト）
↓
システム内部結合テスト（機能間のインターフェースを確認するテスト。例えばデータを受け渡しながら画面遷移をしていく機能等）
↓
システム外部結合テスト（複数のシステム間のインターフェースを確認するテスト。例えば、機能バッチで画面表示の元となるデータを作成しそのデータを用いて画面操作を行う等）
↓
システム総合テスト（業務フローにそって一連の流れを確認するテスト）
↓
運用テスト（顧客側にて実施するテスト）
このように単体テストは最小単位のテストであるが、部署によってはソフトウェア結合テストも含めて「単体テスト」と呼ぶ場合もあるので注意しよう。
単体テストの観点と手法
単体テストの観点として代表的なものを紹介する。
・条件網羅テスト
・境界値テスト
・異常値テスト
条件網羅テスト
おそらく最も一般的なテスト。
ロジックの条件を網羅できるようにテストケースを設定する。
境界値テスト、異常値テスト
異常値テストとは、その名の通り異常となる値を入力してエラーとなることを確認するテスト方法だ。
上記例では、0歳〜99歳までを有効値とした場合の観点をいくつも挙げている。
・小数値（0.01等）
・全角数字
・かな文字や英字
・特殊文字（※）
・入力なし
など
他にも、日付入力については、2021/2/29や2021/6/30などの存在しない日付チェックなどもある。
画面の入力テストでは、特殊文字に対するエスケープの確認は必須。
ちなみにエスケープとは、危険な文字（シングルクオーテーションやバックスラッシュ等）を入力された際に、システム異常が起こらないようにSQLとして処理する前に違う文字に置換すること。細かい説明は割愛する。
単体テスト仕様書の項目と書き方
単体テストを実施するにあたって、単体テスト仕様書（単体テストケース）を作成する。
基本的には過去のプロジェクトの成果物をもとに作成することになるだろうが、上記に一般的な項目や書き方を紹介しておく。
単体テスト仕様書には、①入力操作手順、②期待される結果を記載する。
①入力操作手順
入力データと操作内容・手順を記載する。
違う担当者が単体テストをする場合は、より具体的に書かなくてはならない。
②期待される結果
①の入力操作手順を実施した後に得られるであろう結果を記載する。
「設計書通りであること」とざっくりと書きたくなるところだが、レビュー者がテストケースを確認する際にいちいち設計書を見なくてもいいように具体的に書こう。
単体テスト結果のエビデンス
単体テストを実施する際に最も面倒なのがテスト結果のエビデンスを取ることで、テスト実施の何倍ものエビデンス採取には時間を要する。「エビデンスを印刷して紙で残す」という文化があれば、まさに地獄のような作業時間が必要になってしまう。
エビデンスを残すのは下記の理由があるとされる。
・レビュー時の確認資料
・障害発生時の原因分析資料
まず1つ目だが、悪い担当者だとテストを実施していないにも関わらず「テスト完了」とする可能性があるため、テスト実施の証拠としての効果がある。
2つ目は、第三者がテスト結果を確認することで、担当者が気づかないような不備を検出できる可能性がある。
そして3点目は、後続のテスト工程で障害が発生した際に、「なぜ単体テストで気づかなかったのか？」という原因分析をするのだが、その際の分析資料として利用できる。
このように、単体テストのエビデンスを取ることは一定の効果があると言える。
ただ冒頭で述べたように、単体テストは他のテスト工程と比べてもテストケースも多いためエビデンス採取には膨大な時間を要する。
絶対に避けたいのは、エビデンスを取得する時間に追われてテストが不十分になることだろう。
エビデンスを取る必要があるのかは、組織のルールや契約によって異なると思うので確認をしてほしい。（個人的にはエビデンスの取得など必要ないと考えている）
さいごに
以上、単体テストの目的や観点など基本的な知識を説明してきた。
単体テストは、テストの観点（テストケースの洗い出し）が最も重要だと感じる。特に入力チェック系の不具合は頻繁に起こってしまうため、単体テストフェーズで何とか防ぎたいところだ。
また、今回は紹介しなかったが、テスト工数を削減するツール（テスト自動化ツール）は是非とも採用したい。例えば画面系であれば、途中で不具合を発見してロジックを修正した場合に、一部のテストをやり直さなければならなくなる。こういった手間を少しでも減らすためにツールは活用していきたいところである。（JavaでいえばJUnit等）
参考文献
テスト関係の記事はこちら。
コメントを残す