単体テストとは？メリットや手法、仕様書について詳しく解説！

プログラムを作成したら、設計通り動作するかテストをする必要があります。ですが、いざテストを始めようと思っても、どのように、どのくらいのテストを行えば良いのかイメージが沸かないこともあるのではないでしょうか。

この記事では、テストの中でも初めに行われる、単体テストの手法や注意点、テスト仕様書についてお伝えしていきます。

単体テストとは？どのような目的で行われる？

単体テストとは、プログラムを作成した後に最初に行うテストであり、比較的小さな単位で行うテストのことを言います。通常、関数やメソッドの単位で行われます。

小さな単位でテストを実施し、不具合をあらかじめ見つけておくことで、早期にバグを修正することが可能です。小さな単位のプログラムが正常に動作することが担保されていれば、その後の組み上げやテストの実施を、スムーズに行うことができます。

　

単体テストのメリットとは？課題はある？

単体テストを実施することで、プログラム品質はあがるというメリットがある反面、入力パラメータを振ったり、細かい動作を確認したりと、地道な作業を続けていくためコストがかかる傾向があります。このようにメリットと課題の両方があるため、どちらも理解した上で、単体テストを行うことをおすすめします。

続いて、単体テストのメリットと、課題を詳しく説明します。

単体テストのメリット

1つ目のメリットは、テスト対象となるプログラムが小さいため、不具合を見つけやすいという点です。

例えば、if文の分岐条件として、入力パラメータが5以下のみ正常処理とすべきところを、5を含めない実装をしていたとします。その関数に対して、テストパラメータとして、5を入力してテストを実施すれば、すぐこの関数にバグがあることがわかります。

2つ目のメリットは、プログラムを作成してすぐにテストを行うため、検証をスムーズに行える点です。

プログラム作成直後であれば、実装内容や内部処理も細部まで理解できており、どのあたりを重点的にテストしておけば良いか想定しやすいので、この時に作成したテストプログラムは妥当性が高く、質の高いテストになっていることが多いです。

また、単体テストによってバグが見つかっても、プログラムが理解できているため、修正も的確に行うことができます。

3つ目のメリットは、改善効果が高い点です。

単体テストを行うために、作業時間がかかってしまうものの、単体テストが行える環境を一度整えてしまえば、バグの修正や確認も効率よく行えます。また、時にはバグの修正だけでなく、プログラムをより品質が高いもの修正する際にも（リファクタリング）、単体テストを使った動作確認が役立ちます。

単体テストの課題

メリットが多くある一方で、課題もあります。次は課題についてご紹介します。

1つ目の課題は、テストコードの作成に時間がかかることがあげられます。

例えば、関数の単体テストを実施したい場合、その関数を呼び出すためのテストコード（スタブ）が必要ですし、そのテストコードは、関数の引数を変化させて何回も呼び出していくくようになります。また、テスト対象の関数が別のコードを呼び出す場合には、代替となる簡易的なコード（モック）の用意が必要になる時もあります。単体テストを実施するために準備するものが多く、時間がかかってしまう傾向があります。

2つ目は、テスト実施者のスキルによって、単体テストの効果が異なることでしょう。

テストコードを用意する時に、関数へのパラメータとして設定する値を選択するにも、スキルが必要です。適当な値を入れるだけでは、効果的なテストにならないため、不具合が発生しやすい条件のパラメータを設定し、テストを実施する必要があります。

また、モックを作成しなければならない場合、代替として正しく動作を再現するコードを実装する必要があります。このように、テスト実施者のスキルによって、効果がかなり変わってきます。

3つ目は、単体テストが重要視されずに後回しにされる場合が多い点です。

上記2つの課題で挙げたように、単体テストの実施にはかなりの労力と時間がかかります。スケジュールが厳しくなったことにより、単体テストの時間をとれないため、簡易的なテストで終わってしまう場合もあります。また、テスト対象の関数を機能アップデートなどにより修正したものの、テスト自体は実施されなかったり、テストコードのメンテナンスが行われなかったために、テストが実施されなかったりする場合もあります。

　

単体テストの手法を結合テストや他のテストとの違いを含めて解説！

ここからは、実際に単体テストを行うおうとした時に、どのような手法があるのか他のテストとの違いを含めて解説していきます。

プログラムのテストは単体テスト以外にも、開発のフェーズによって、いくつかあります。

• 結合テスト

単体テストの次に行うテストで、複数のプログラムを結合した状態で正常に動作するかを確認します。単体テストと違い、単体のプログラムの動作のみをテストするのではなく、複数のプログラムを組み合わせて実際に動作する状態で、それぞれ仕様通りに動いているかどうかの確認をします。

• システムテスト（統合テスト）

単体テスト→結合テストと完了し、動作が安定した終盤で実施するテストです。

単体テストのように、プログラムのテストではなく、実際に顧客が使用する状況を想定し、本番環境と同等の環境でテストを実施します。顧客がどのように使用するか、あるいは誤った使われ方をされた時に、エラーが表示されるかなど、システム全体を通してあらゆることをテストします。

結合テストやシステムテストでは、個々のプログラムのテストは行わないことが多いため、単体テストの段階でプログラム単体の不具合を取りのぞいておく必要があり、システム開発の中でも重要な役割を担っております。

単体テストは、一般的に2つの手法を用いて実施されることが多いです。

続いて、その2つの手法を詳しくお伝えしていきます。

単体テストの手法①ホワイトボックステスト

ホワイトボックステストとは、プログラム内部の構造を理解した上で実施するテスト手法です。プログラムの内部が想定した通り動作しているかを確認することが目的のテストです。そのため、分岐条件などプログラムの中身をしっかり理解した上で、テストを実施する必要があります。

ホワイトボックステストでは、テストによってどこまで内部処理内容を網羅するか決めて実施することが重要です。

その網羅基準（カバレッジ基準）は以下になります。

• 命令網羅
  全ての処理を最低1回は通るようにする
• 分岐網羅
  全ての分岐を最低1回は通すようにする。分岐先に注目したテスト　　
• 条件網羅
  条件の分岐に対して、真と偽を1回は通すようにする。分岐条件に注目したテスト
• 複数条件網羅
  条件の分岐に対して、条件の組み合わせの全てを網羅するようにする。

網羅基準よって、テストの準備コストが変わるため、どの基準でテストを実施するかは、対象となるコードの重要性やプロジェクトの状況などによって、選択することが多いです。

単体テストの手法➁ブラックボックステスト

ブラックボックステストとは、プログラムの内部構造は知らない状態で、外部仕様に対して、テストを実施するものです。内部のことは分からない状態でテストを行うため、よりユーザーが使用することを想定したテストになります。内部構造を知っていると、テスト内容が偏ってしまうことがありますが、ブラックボックステストでは、システムを包含的にテストしていくため、設計者の想定漏れなどを見つけることができます。

テスト項目は外部仕様書を参照し、入力値やUI操作に対して、期待する結果になることを確認するものになります。このテスト項目は、「同値分割法」と呼ばれる、正常処理が行わる有効な値の代表的な条件を選択したり、「境界値分析」と呼ばれる、正常処理と異常処理が分かれる境界条件をテストする手法で作成されたりします。

　

単体テスト仕様書の書き方や項目一覧

単体テストを実施する前に、単体テスト仕様書を作成します。

単体テストは仕様書に従って、テストが実施されるため、重要な資料となります。

単体テスト仕様書には下記のような内容を記載します。

• テスト対象となるプログラムの範囲や、テストを実施する環境
• テスト対象プログラムに対して、どのような手法でテストを行うか（例：ホワイトボックステストなのか、ブラックボックステストなのか）
• テストを実施するための操作手順
• テスト項目一覧
• 期待する結果や、実行後の結果

単体テスト仕様書を作成する目的は主に下記の3つがあります。

• 第3者にレビューしてもらうことができ、網羅性が確認できる
• 手順を記載することで、別の人が実施する場合でも安易に再現できるようにする
• テスト項目が明確になっていることにで、ゴールが明確になる

この目的を達成するため、テスト観点が不足していないか、テスト観点が不明確だったり、分かりにくい表現の記述になっていたりしないかなどに注意する必要があります。

　

単体テストはどこまですればいい？実施時の注意点

最後に、単体テストを実施する際の注意点について解説します。

1つ目の注意点は、単体テストは完了が明確でないことです。テスト項目をどれくらい作成し、実施したら不具合がないプログラムかを定義することは難しいので、どこまでやるかはテスト設計者が決めていくことになります。

テスト項目数を増やすことで、バグ発見確率は上がりますが、その分時間もかかってしまうため、バランスが重要です。

これを防ぐ一つの方法としては、テスト設計をしっかり行い、テスト有識者とレビュー・合意を取ってゴールを明確にしてからテストを実施することです。テスト設計時に上げた項目が全て合格となれば完了とするという条件にしておくことで、どこまでやれば良いか分からなくなってしまうことを防げます。

2つ目の注意点は、不具合や対応履歴の管理を徹底し、テストを実施した証拠を結果に残す必要があることです。単体テストを開始する前に、テスト一覧を作成していると思いますので、その一覧に結果を記入し、証拠を残していくことが重要です。

結果を残す目的は下記になります。

• テストを確かに実施した証拠を残す。時間が経過すると、テストを実施したことすら曖昧になることがある。
• 第3者がテスト結果をレビューした時に、結果の判定の仕方が間違っているため、実はNGであったということに気づける。
• 結合テスト、統合テストによって不具合が見つかった場合に、単体テストでは動作していることを確認できる。

　

今回の記事では、プログラムを作成し、最初に実施する単体テストについて解説しました。単体テストをしっかり実施していくことで、不具合もなくなり、プログラムの品質が向上します。まずはいきなり大規模な開発からではなく、小規模のプログラムから、テスト仕様書を作成し、単体テストの流れをつかんでみてはいかがでしょうか。