単体テストとは？

単体テスト(Unit Test, UT)とは、モジュール/プログラムなど、機能単体の挙動を確認するテストです。プログラムの最小単位で動作確認を行うことで、早い段階でバグの発見・修正を行うことができます。

単体テストによって、ユニットごとの動作が担保される

単体テストを行うことで、ソフトウェアの最小単位（ユニット）が正しく動作するかを確認できます。

システムは複数の機能・画面から構成されています。単体テストによって1つ1つの画面・機能の動作を検証することで、プログラムの基本的な機能やエラー処理などの機能に不具合がないか確認し、後の作業での手もどりの発生リスクを抑えることが可能です。

単体テストと結合テストの違い

単体テスト	プログラムの最小単位（プログラム/モジュール）が正しく動作することを確認する
結合テスト	単体テストを終えたプログラム/モジュールを組み合わせた時に、システムが正常に動作するか検証する

単体の機能をテストするのが単体テスト、組み合わせたプログラム/モジュールの動作を確認するのが結合テストです。通常、単体テストの後に結合テストが実施されます。

単体テストの手法 

単体テストの手法には、ホワイトボックステスト・ブラックボックステストの2種類があります。ここからは、それぞれの手法について詳しく紹介します。

ホワイトボックステスト

• システムの内部構造を深く理解/して実施する
• 内部構造が正しく作られているか確認する
• 開発担当者がテストを行う

ホワイトボックステストとは、システムの内部構造を深く理解した上で規定の処理を実行した結果、正しい順番で期待通りの処理が実行されているか確認するテストです。

仕様を理解した開発者が網羅的に検証を行うため、システムの耐久性を高めることができるほか、開発の初期段階で不具合を修正できるので、手戻りのリスクをより抑えることができます。

一方、開発担当者が手を動かさなければいけないので費用がかかるほか、あくまで仕様の確認を行うだけでUIなどユーザー目線での快適さは評価できない などのデメリットも存在します。

ブラックボックステスト

• システムの内部構造を理解/考慮せずに実施する
• 仕様を満たしているかを確認する
• 開発担当者以外の第三者がテストを行う

ブラックボックステストとは、システムの内部構造を理解していない人が規定の処理を実行した結果、仕様通りの動作が発生するかを確認するテストです。

開発担当者以外の第三者がテストを行うため費用対効果が高いほか、ユーザーの目線に立った動作の検証を行うことができるというメリットがあります。

一方、入出力の結果だけを確認するため、必ず規定通りに処理が行われる構造になっているのかを確認することはできません。また、開発担当者ではない第三者がテストを行う都合上、テストの事前準備として、開発担当者が仕様書からテストの優先度が高い項目を洗い出すなどの手間もかかります。

単体テストのやり方3ステップ

単体テストは ①仕様書の作成 ②テストの実施 ③結果の記録・プログラムの修正 という3ステップで進められます。ここからは、単体テストの進め方について詳しく紹介します。

①仕様書の作成

まず最初に、仕様書を作成します。仕様書を作成する際のポイントは、以下の通りです。

• 開発当初の「要件定義書」をもとに、重要な機能を書き出す
• テストの観点を記載する
• テストの方法を記載する

単体テストをより網羅的で質の高いものにするためにも、仕様書を通して、テストを優先するべき重要な機能やテストの観点などを関係者とすり合わせる必要があります。

依頼者やテスターが目を通すものなので、仕様書を作成する際は、どんな人でも理解しやすい書面にすることも大切です。

②テストの実施

次に、テストを実施します。テスト実施の手順は以下の通りです。

• テストコードを作成する
• テストデータを準備する
• テストを実行する
• 不具合/バグを修正する
• 結果の確認と記録を行う

仕様書に基づいて適切なテストコードを作成したあとは、定義されたテストケースに基づいてテストデータを準備します。単体テストは比較的作業工数が多いため、このテストケースを都度確認しながら、1つ1つ丁寧に作業を進めていくことが大切です。

③結果の記録・プログラムの修正

最後に、テスト結果を記録し、不具合/バグが見つかった箇所には修正を行います。ここでのポイントは以下の通りです。

• 発見された不具合の原因を分析すること
• 修正したプログラムの周辺機能までチェックすること
• 修正後に、検証テストを実施すること

ここで大切なのは、不具合/バグの修正後は、周辺機能を再度チェックすることです。1つの不具合を直した結果、それまで正常に動いていた機能に不具合が生じることは、よくあります。

そのため、周辺機能まできちんと確認し、修正後に再度検証テストを実施することが大切です。

単体テストのメリット

単体テストのメリットは主に①低コストで実行できること ②簡単に不具合の修正ができること ③リファクタリングを行いやすいこと の3点です。ここからは、単体テストのメリットを詳しく紹介します。

低コストで実行できる

1つめは、低コストで実行できることです。単体テストは結合テストや受け入れテストなどのテストと比べると自動化しやすいため、比較的短い期間でテストを完了できます。

システム開発の費用のほとんどは人件費が占めているため、数秒で繰り返し実行・改善できる単体テストは、そこまでコストをかけず結果を得られるテストだといえます。

簡単に不具合の修正ができる

2つめは、早い段階で問題を発見できることで、簡単に不具合を修正できることです。

単体テストの場合、ソフトウェアの最小単位を対象にテストを行うため、結合テストなど、ほかのテストと比較して問題の特定・修正をしやすいです。

リファクタリングを行いやすい

3つめは、リファクタリングを行いやすいことです。

リファクタリングとは、ユーザーに見える外的な挙動は変更せず、システムの内部構造にだけ変更を加えること。コードの構造を最適な形に維持するために、大切な作業です。

単体テストの場合ソフトウェアの最小単位を対象にテストを行うため、外的な挙動に問題があればその箇所を簡単に特定し、リファクタリングを実施できます。

単体テストのデメリット

単体テストのデメリットは主に①テストコードの作成に時間がかかること ②テストの品質が担当者のスキルに依存すること の2点です。ここからは、単体テストのデメリットを詳しく紹介します。

テストコードの作成に時間がかかる

1つめは、テストコードの作成に時間がかかることです。

単体テストの際は、1つ1つのプログラム/モジュールの機能に対してテストを行うため、相応の準備時間が必要です。

テストケースが多いほどスケジュール的にも大きな負担がかかるため、実施の際は十分なリソースを用意する必要があります。

テストの品質が担当者のスキルに依存する

2つめは、単体テストの効果が担当者のスキルに依存することです。

単体テストを効果的なものにするためには、不具合が起きやすい箇所を事前に想定して、テストケースやテストデータを用意する必要があります。これには、一定以上のスキルが必要です。

高いスキルを持つ開発者に依頼できないと、テストの品質が低下してしまうということは、大きなリスクになると言えるでしょう。

単体テストを実施する際の注意点

単体テスト実施の際の注意点は①テストのゴールを明確に設定すること②テスト結果は必ず記録することの2点です。

テストのゴールを明確に設定すること

まずは、テストのゴールを明確にしましょう。

もちろんテストパターンを増やすほど不具合/バグを見つけられる可能性は高まりますが、開発に当てられる工数には制限があります。

テストのゴールを明確に設定し、それを必要最低限満たせるように検証範囲を限定することで、不必要なテストを排除してテストの効率を高めることが可能です。

テスト結果は必ず記録すること

テスト結果をきちんと記録することも大切です。

テスト結果を記録しておくことで、不具合/バグに対処したことや、テストを通して品質を確保していることを証明できるからです。

記録がないとテストを実施した事実すら示すことができなくなってしまいます。開発担当者内できちんと情報を共有するためにも、依頼者側に正しく報告を行うためにも、テスト結果はきちんと記録・管理しておきましょう。

単体テストは、綿密な準備の上で進めましょう

ここまで、単体テストの目的や実施のポイントについて紹介してきました。単体テストは、開発の中で発生した不具合を早期に発見・解消するために大切な役割を持っています。

限られた時間で質の良いシステム開発を行うためには、最適なテストを最適なタイミングで丁寧に行う必要がありますが「なかなか信頼できる開発会社と出会えない」とお悩みを持っている方も多いようです。

弊社BLUEWIND ASIAは、フィリピンのセブ島でオフショア開発の支援を行っております。

時差が小さい、かつ必ず窓口に日本人の担当者を配置しますので、オフショア開発においてネックになりがちな時差・言語・文化の障壁なく、スムーズにコミュニケーションをとり、プロジェクトを進行できると好評をいただいております。

また、日本の大手企業さまとのお取引実績もすでに50件以上。実績面・技術面でも安心をお届けすることができるかと考えております。

「自社の体制にオフショア開発は向いているか？」「予算や開発期間の目安は？」など、小さなことからでも構いません。