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

このセクションの内容

前提条件

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

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

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

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

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

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

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

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

独立した単体テスト

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

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

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

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

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

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

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

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

基本的な手順 

ステッププロジェクト スコープファイル スコープ (独立)

1: テスト コンフィギュレーションをセットアップします。

ホスト ベースのテストの場合、テスト生成、スタブ生成、テスト実行を行うビルトイン コンフィギュレーションは、何も修正しなくても動作するはずです。しかし、ビルトイン コンフィギュレーションを複製して使用することは、テスト環境の一貫性を保証する上でよい習慣です。複製したコンフィギュレーションは必ず名前を変更して、簡単に識別したり目的を覚えられるようにします。プロジェクト スコープの場合と同じ。
2: テスト対象のクラスを選択します。テスト スコープはプロジェクト全体に拡大されますが、選択したコードに関連付けられた単体テストだけが実行されます。テスト スコープを設定するには、プロジェクト内のソース ファイルを選択します。単体テストを実行したときに未定義シンボルのエラーが発生するのを防ぐため、スタブの生成時と同じスコープかまたはそのスコープのサブセットを選択します。
3: 単体テストを生成します。[Generate Unit Tests] テスト コンフィギュレーションを実行してテスト インフラストラクチャのセットアップとテスト スイートの作成を行います。テストの生成はプロジェクト スコープでもファイル スコープでも変わりがないため、生成されたテスト ケースはどちらのテスト スキームでも使用できます。テストが生成されたら、プロジェクト ツリーでテスト スイートのソースコードを開いたり、テスト ケース エクスプローラーを使用して、生成されたテスト コードをナビゲートできます。プロジェクト ツリーでテスト スコープを選択し、上記で作成したテスト生成コンフィギュレーションを実行します。単体テスト スコープ外のソース用のテストがある場合、それらのテストは実行されません。スコープ内のコード用のテストがない場合、コードはテストされません。テストが生成されたら、プロジェクト ツリーでテスト スイートのソースコードを開いたり、テスト ケース エクスプローラーを使用して、生成されたテスト コードをナビゲートできます。
4: スタブを生成します。

スタブ ビューでシンボルの使用状況を可視化できます。スタブ ビューを開いてシンボル、定義タイプ、場所を表示するコンフィギュレーションが用意されています。このコンフィギュレーションを使用する場合、コンフィギュレーションを複製して名前を変更することを推奨します。スタブが生成される前に、利用できないシンボルまたはオリジナル定義を使用している (オリジナルのコードがスコープ内にある) シンボルが スタブ ビューに表示されます。スタブが生成された後、すべてのシンボルが「オリジナル」または「自動」として定義されたことを確認します。ユーザースタブを作成した場合、「ユーザー定義」として表示されます。

スタブを自動生成するには、プロジェクト ツリーでテスト スコープを選択し、スタブ生成テスト コンフィギュレーションを実行します。デフォルトでは、スタブはプロジェクトの stubs/autogenerated ディレクトリにソース コードとして生成されます。すべてのシンボルについてオリジナル定義が利用可能な場合はスタブは生成されません。スタブ ビューを参照してすべてのシンボルが定義済みかどうかを確認します。

プロジェクト スコープの場合と同じ。

5: 単体テストを実行します。

テスト対象のファイルを選択してテストを実行するコンフィギュレーションを実行します。生成されたテスト インフラストラクチャ、テスト スイート、スタブからテスト実行可能ファイルが生成されます。テスト実行可能ファイルが実行され、テスト結果が C++test GUI にロードされ、ユーザーが解析できるようになります。

C++test テスト ケース エクスプローラーを使用して実行対象のテスト ケースを参照したり選択することもできます。選択したファイルまたはテスト ケース以外のコードのためのテストは無視されます。選択したコードのためのテストがない場合、コードはテストされません。

プロジェクト スコープの場合と同じ。その他の注意点: テスト スコープを選択するとき、スタブの生成時と同じスコープかそのスコープのサブセットを選択します。

単体テストの演習の概要

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

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

演習のセットアップ

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

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

  1. 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++test を起動し、作成した ATM 親ディレクトリに新しいワークスペースを作成します。

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

6.[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++test パースペクティブでも操作できます。

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

演習


  • No labels

Need assistance? Visit our support page