このレッスンでは、単体テストのさまざまな側面をカバーする演習を行います。演習で学ぶ実践的なテストの知識とともに、概要で説明する情報を参照すると、要件に合わせてテスト方針を体系化することができます。C/C++test でのテストの実行とカバレッジ解析の詳細については「単体テスト」の章を参照してください。

このセクションの内容

前提条件

ATM プロジェクトがワークスペースになければなりません。ATM プロジェクトの作成の詳細については「C/C++test プロジェクトの作成－チュートリアル」を参照してください。

C/C++test での単体テストの概要

テストを実施するには、以下を定義し理解する必要があります。

テストの目的 / 要件
テストのメトリクス
テストの戦略
テストの予算

「独立したテスト」と「プロジェクトスコープでのテスト」

テスト方法の選択の 1つとして、単体テストを独立して行うか、プロジェクト全体のスコープで API テストを行うかの選択があります。

独立した単体テストとは、テスト対象ファイルの外で定義された関数を原則的に使用しないテストを作成することを意味します。外部で定義された関数は、テストの目的に応じてスタブに置き換えられます。
プロジェクトスコープでの単体テストまたは API テストでは、利用可能なすべての外部関数を使用する完全に結合されたテストが作成されます。この結果、必要なスタブの数が大幅に少なくなり、またテストセット中のそれぞれのテストで複数の関数を実行できるため、より少ないテストでより包括的なテストカバレッジが得られます。

どちらのテスト方法にもそれぞれ長所と短所があります。しかし、通常はプロジェクトの要件やソフトウェア開発ライフサイクルのテストフェーズ計画によってテスト方法が決まります。C/C++test は両方のテスト方法をサポートするだけでなく、混合されたテスト手法もサポートします。

独立した単体テスト

プロジェクトのテスト要件により、独立した単体テストが義務付けられている (コードを統合する前に低レベルの機能の検証することを目的としている)。
新規に開発されたソースコードとテストを同時に提出する必要がある。独立した単体テストは、対象ファイルがコンパイルできるようになれば、すぐ実行できます。
プロジェクトが他と同時進行で作成されていて、テストを作成する開発者が、依存するコンポーネントやクラスの大部分を利用できないことが多い。

独立した単体テストは、一般的にセットアップ作業が少なく、少数のファイルを対象としてテストが開始されます。小規模のファイルセットを処理するため、テストの準備を含めた C/C++test の実行時間は非常に短くなります。ただし、大規模なファイルセットに対して独立した単体テストを実行する場合は、スタブの定義やスタブファイルの管理に注意する必要があります。

独立したテストの過程で作成されたテストは、多くの場合、後のテストサイクルでプロジェクトレベルのテストにも再利用できることに注意してください。テストの目的に合わせて特定のソースファイル、ライブラリ、スタブファイルを使用したり無視したりすることで、テスト対象のコードとシステムの残りの部分の結合を調整できます。C/C++test のテストコンフィギュレーションのさまざまな設定を通じてこのような調整を行うことができます。

プロジェクトスコープでの単体テスト

プロジェクトが、既存のコードの追加修正である。
プロジェクト全体の機能性/ユースケースを検証することが、100 パーセントのコードカバレッジを達成することより重要である。

プロジェクトスコープでテストするということは、明示的に「ユーザー定義」スタブとしてスタブ化しない限り、テスト対象として選択したスコープが、プロジェクト内で定義されたすべてのシンボルを含む範囲に拡大されることを意味します。

プロジェクトレベルの単体テストは、C/C++test のテストフローを準備および実行するためにより長い時間を必要とする可能性があります。しかし、これは単に時計で測った時間に換算した場合です。通常は、プロジェクトベースのテストをセットアップするために必要な全体的な労力はより少なくなります。

プロジェクトのすべてのシンボルが解決済みで正常にリンクでき、単体テストの第一の目的がコードカバレッジの要件を達成することである場合、最良の方法は最初にプロジェクトスコープでの単体テストを行うことです。これに加えてクラスベースのテストを行うこともできますが、その場合も選択したクラスのカバレッジを上げる際に、プロジェクト内の他のコードもテストされてカバレッジがレポートされます。

基本的な手順

ステップ	プロジェクトスコープ	ファイルスコープ (独立)
1: テストコンフィギュレーションをセットアップします。	ホストベースのテストの場合、テスト生成、スタブ生成、テスト実行を行うビルトインコンフィギュレーションは、何も修正しなくても動作するはずです。しかし、ビルトインコンフィギュレーションを複製して使用することは、テスト環境の一貫性を保証する上でよい習慣です。複製したコンフィギュレーションは必ず名前を変更して、簡単に識別したり目的を覚えられるようにします。	プロジェクトスコープの場合と同じ。
2: テスト対象のクラスを選択します。	テストスコープはプロジェクト全体に拡大されますが、選択したコードに関連付けられた単体テストだけが実行されます。	テストスコープを設定するには、プロジェクト内のソースファイルを選択します。単体テストを実行したときに未定義シンボルのエラーが発生するのを防ぐため、スタブの生成時と同じスコープかまたはそのスコープのサブセットを選択します。
3: 単体テストを生成します。	[Generate Unit Tests] テストコンフィギュレーションを実行してテストインフラストラクチャのセットアップとテストスイートの作成を行います。テストの生成はプロジェクトスコープでもファイルスコープでも変わりがないため、生成されたテストケースはどちらのテストスキームでも使用できます。テストが生成されたら、プロジェクトツリーでテストスイートのソースコードを開いたり、テストケースエクスプローラーを使用して、生成されたテストコードをナビゲートできます。	プロジェクトツリーでテストスコープを選択し、上記で作成したテスト生成コンフィギュレーションを実行します。単体テストスコープ外のソース用のテストがある場合、それらのテストは実行されません。スコープ内のコード用のテストがない場合、コードはテストされません。テストが生成されたら、プロジェクトツリーでテストスイートのソースコードを開いたり、テストケースエクスプローラーを使用して、生成されたテストコードをナビゲートできます。
4: スタブを生成します。	スタブビューでシンボルの使用状況を可視化できます。スタブビューを開いてシンボル、定義タイプ、場所を表示するコンフィギュレーションが用意されています。このコンフィギュレーションを使用する場合、コンフィギュレーションを複製して名前を変更することを推奨します。スタブが生成される前に、利用できないシンボルまたはオリジナル定義を使用している (オリジナルのコードがスコープ内にある) シンボルがスタブビューに表示されます。スタブが生成された後、すべてのシンボルが「オリジナル」または「自動」として定義されたことを確認します。ユーザースタブを作成した場合、「ユーザー定義」として表示されます。スタブを自動生成するには、プロジェクトツリーでテストスコープを選択し、スタブ生成テストコンフィギュレーションを実行します。デフォルトでは、スタブはプロジェクトの stubs/autogenerated ディレクトリにソースコードとして生成されます。すべてのシンボルについてオリジナル定義が利用可能な場合はスタブは生成されません。スタブビューを参照してすべてのシンボルが定義済みかどうかを確認します。	プロジェクトスコープの場合と同じ。
5: 単体テストを実行します。	テスト対象のファイルを選択してテストを実行するコンフィギュレーションを実行します。生成されたテストインフラストラクチャ、テストスイート、スタブからテスト実行可能ファイルが生成されます。テスト実行可能ファイルが実行され、テスト結果が C/C++test GUI にロードされ、ユーザーが解析できるようになります。 C/C++test テストケースエクスプローラーを使用して実行対象のテストケースを参照したり選択することもできます。選択したファイルまたはテストケース以外のコードのためのテストは無視されます。選択したコードのためのテストがない場合、コードはテストされません。	プロジェクトスコープの場合と同じ。その他の注意点: テストスコープを選択するとき、スタブの生成時と同じスコープかそのスコープのサブセットを選択します。

単体テストの演習の概要

以降の演習は、プロジェクトをテストする際に使用される可能性が高い順に進みます。このフローは、コーディングが完了してすべての機能が利用できるようになる前にテストを実行しなければならないことを想定しています。最後の演習では、テスト結果に基づいてさまざまなレポートを生成する方法を取り扱います。

単体テストのセットアップと管理には、テストコンフィギュレーションを使用します。ビルトインコンフィギュレーションはテンプレートとしてだけ使用します。ビルトインコンフィギュレーションを複製してユーザー定義コンフィギュレーションを作成すれば、ニーズに合わせて設定を変更できます。以降の演習では、いくつかのテストコンフィギュレーションを作成します。それぞれのテストコンフィギュレーションの詳細については、個々の演習で説明します。これまでの演習でテストコンフィギュレーションの複製と変更を行っていることを前提としています。

演習のセットアップ

以降の演習の準備として、「C/C++test プロジェクトの作成－チュートリアル」に従って、ATM サンプルコードを新しくコピーしてプロジェクトをセットアップする必要があります。

GNU ホストベースのテスト手順

C++test ATM サンプルコードを使って単体テストのためのプロジェクトディレクトリを作成します。

- 例: C:\C++test\Tutorial\ATMEclipseGnu\ATM

2.作成したディレクトリに、[C++test install directory]\Examples\ATM から以下のファイルをコピーします。

- Makefile
- Account.cxx
- ATM.cxx
- Bank.cxx
- BaseDisplay.cxx

3.C:\C++test\Tutorial\ATMEclipseGnu\ATM\include ディレクトリを作成し、次のファイルをこの include ディレクトリにコピーします。

- Account.hxx
- ATM.hxx
- Bank.hxx
- BaseDisplay.hxx

4.Windows 環境に gcc、g++、make などへのパスが設定されていることを確認します。

5.C/C++test を起動し、作成した ATM 親ディレクトリに新しいワークスペースを作成します。

- 例: C:\C++test\Tutorial\ATMEclipseGnu\workspace

6.[C/C++test] パースペクティブで [ファイル] メニューの [新規] > [プロジェクト] をクリックします。

7.[C/C++] を展開して [C++プロジェクト] を選択し、[次へ] をクリックします。

8.[プロジェクト名] フィールドに「ATM」と入力します。

[デフォルト・ロケーションの使用] チェックボックスをオフにします。

10.[参照] ボタンをクリックして ATM の Makefile の場所を指定します。

- 例: C:\C++test\Tutorial\ATMEclipseGnu\ATM

11.[プロジェクト・タイプ] の [Makefile プロジェクト] > [空のプロジェクト] を選択します。

12.[ツールチェーン] から[Cygwin GCC] を選択します。

13.[終了] をクリックします。

14.関連付けられたパースペクティブを開くかどうかを訊ねるダイアログが表示された場合、好みに合わせて選択してください。C/C++ パースペクティブでも C/C++test パースペクティブでも操作できます。

15.ATM.cxx を静的解析し、プロジェクトのセットアップが正しいかどうかをチェックします。静的解析の実行の詳細については「静的解析とコーディングスタンダード－チュートリアル」を参照してください。

Page tree

Tutorial - Unit Test Generation and Execution