単体テストとは？一つのプログラム(モジュール)に対する動作確認

単体テスト(単体試験)とは、「一つのプログラム(モジュール)に対する動作確認」のことです。

UT(Unit Test)と呼ばれたり、PT(Part Test)と呼ばれたりするけど、開発プロジェクトの文化次第。

基本情報技術者試験の文中には、「モジュール」なんて難しい言葉で出てくるけど、簡単に言えば「一つ一つの部品(プログラム)がちゃんと動くよね？」という確認をします。

一つ一つの部品を最終的には合体させて、「ホテル予約システム」なり「在庫管理システム」なり「会計システム」なり、誰かが使える「システム(製品)」になるのだけれども。

部品を合体させる前に、それぞれの部品をしっかりとテストするのが単体テストです。

単体テストとは、一つのプログラム(モジュール)に対する動作確認

単体テストとは、一つのプログラム(モジュール)に対する動作確認です。「基本設計書」(外部設計書)や、「詳細設計書」(内部設計書、モジュール設計書)通りに動くか？を見てあげる作業。

その前に、モジュールとは何かについて、簡単に説明します。

「モジュール結合度とは？プログラムの部品同士のくっつき度合い」と説明がかぶりますが、モジュールとは、「プログラムの部品」のこと。

例えば、ドラクエ。

実際のドラクエの作りはわからないけど、冒険の書を作ってオープニングムービーが流れるまでに、

の2つのプログラム(モジュール)があると仮定します。

「ドラクエ」というゲームは、冒険の書だけ作っても意味がないし、オープニングムービーを流して終わりでもありません。魔王を倒すまでがドラクエです。

冒険の書を作る→オープニングムービーを流す→・・・

みたいに、それぞれの部品(モジュール)が、いくつも合体して「ドラクエ」と言う製品が完成します。

「冒険の書をつくるプログラム」は、一つの部品(モジュール)として単体でも機能するので、「『冒険の書をつくるプログラム』をしっかりとテストしてやりましょう」っていう話が単体テスト。

たとえば、こんなことをテストします。

「冒険の書をつくるプログラム」をピンポイントでテスト。プログラム単体が正しく動くかを、「詳細設計書」(内部設計書、モジュール設計書)にもとづいて、試験してやります。

テストして不具合(バグ)が見つかれば、設計書が間違ってるかもしれないし、プログラムがおかしいかもしれないので、原因を特定して1つ1つ修正します。

単体テストでやるべきことや、見るべき観点を簡単に書いておきます。

ホワイトボックステストでは、「○○の場合は、▲▲」みたいな細かい分岐をすべてテストしてあら探し。

まともにやると量がかなり多いので、テスト実行用のプログラムを別に用意することもあります(Javaであれば、JUnit)。

ブラックボックステストであれば、実際に画面を操作して、結果がどうなったかだけを注目するイメージです。

単体試験の範囲は、別のモジュールとの結合(インターフェース結合、別のプログラムの呼び出し)ができるところまでを担保します。

※「別のプログラム」が未完成であれば、ドライバ(呼び出し元の仮プログラム)やスタブ(呼び出し先の仮プログラム)を作ったりするけど、話がややこしくなるので、ここでは考えないでおきます。

「冒険の書をつくるプログラム」の例でいけば、「オープニングムービーを流すプログラム」を呼び出すことができるところまで、担保します。「呼び出せればOK」です。

「冒険の書」⇒「オープニングムービー」の順でドラクエが進んでいって、おかしなことにならないかは、結合テストという次のテスト工程で確認します。

単体テスト(単体試験)ときたら、「一つのプログラム(モジュール)に対する動作確認」のことです。

UT(Unit Test)と呼ばれたり、PT(Part Test)と呼ばれたり、仕事する場所によっていろいろです。

「モジュールがどうたら」みたいに書くと難しそうだけど、やりたいことは「一つ一つの部品(プログラム)がちゃんと動くよね？」という確認。

1つ(単体)のモジュールが設計した通りに動けばよし。さらに別の(後続の)プログラムが呼び出せさえすれば、単体テストではカンペキ。「呼び出した結果がどうなるか？」は、実際にモジュールを合体させて結合テストで検証します。

プログラム単体のテストをして不具合(バグ)が見つかれば、設計書のおかしなところを直したり、プログラムを修正する作業を、1つ1つ地道にやるものだと思ってくださいまし(-_-;)。

基本情報技術者で勉強前に知りたいこと

基本情報技術者の個別の対策