このセクションでは、「Wind River Tornado コンパイラを使ってコンパイル/ビルドされるコード」および「Wind River Tornado IDE を利用して作成されるコード」に対して単体テストを実行する方法について説明します。

このセクションの内容:

単体テストとは

「単体テスト」という用語には、テスト オブジェクトのビルドと実行に関連するあらゆることが含まれます。単体テストを実行する前に、C++test の次の用語/機能に慣れておくと役立ちます。

• 生成 テスト スイート中にグループ化してテスト ケースを生成すること。  
• インストゥルメント テスト オブジェクトの実行時に C++test が情報を収集できるように、テスト対象のソース コードを変更すること。インストゥルメント機能はユーザーがカスタマイズできます。  
• カバレッジ テスト対象のソース コードをどの程度テストがカバーしているかを測定すること。  
• スタブ化 テスト オブジェクトの正常なビルドと安全な実行を容易にするために、「使用したくない/安全ではないルーチン」および「欠けているルーチン」の代替を生成すること。  
• ランタイム ライブラリ 「ランタイム ライブラリのビルド」 を参照してください。  
• テスト オブジェクトのビルド:テスト オブジェクト ( ソース ファイルおよびテスト スイートから生成される最終成果物) を正常にビルドするために必要なあらゆる物と、実行時データ (テスト ケースの結果やカバレッジ データなど) を収集するために実行しなければならないあらゆる物が該当します。  
• 実行 テスト オブジェクトを実行するプロセス。実行時データはこのフェーズ中に収集され、フェーズ終了後に提示されます。  

VxWorks テスト オブジェクト/再配置可能テストは -r オプションを使ってリンクされるため、シンボル (関数/変数) 定義の存在はチェックされません。そのため、シンボルの解決エラーはリンク時にレポートされません。結果として、ユーザーは実行フェーズでテスト オブジェクトがクラッシュするときまで、シンボルの定義を忘れたのか、あるいはシンボルのインクルードを妨げるようなスコープの間違いがあったのかを知ることができません。このような問題について早い段階で警告を受け取るには、テスト コンフィギュレーションの [実行] > [シンボル] タブで [未解決シンボルが検出された場合は実行を中断する] オプションを有効にして、生成される外部 VxWorks イメージ シンボルを使用するように設定する必要があります。 設定の詳細については 「外部シンボル リストの作成」を参照してください。

単体テストを正常に実行するには、すべてのプロジェクト設定を適切に行う必要があります。プロジェクト設定の詳細については 「ターゲット/プラットフォーム依存のオプションの設定」 を参照してください。

以降のセクションでは、C++test ランタイム ライブラリをビルドする方法 (よりきめ細かく制御するためにカスタマイズして手動でビルドする場合)、VxWorks イメージから外部シンボル リストを生成する方法、テスト オブジェクトを実行するために必要な Tornado ツール、Tornado テストのためのビルトイン テスト コンフィギュレーション、および組込みテストの状況に合わせてテスト オブジェクトを調整できるテスト実行フローのカスタマイズ方法について説明します。

単体テストの詳細については 「テストの作成と実行」を参照してください。

ランタイム ライブラリのビルド

ランタイム ライブラリの詳細については 「 C++test ランタイム ライブラリのビルド」 を参照してください。

例: Tornado を使って VxWorks のためのランタイム ライブラリをビルドする

Tornado ツールを使って VxWorks OS のためのランタイム ライブラリをビルドするには、次の操作を行います。なお、この操作は必要な Tornado 環境変数を正しく設定済みであることを前提とします。詳細については 「要件 」 を参照してください。

1. ランタイム ライブラリのソースのルート ディレクトリ (C++test_install_dir/engine/runtime)に移動します。  
2. 次のコマンドを入力します。
   make TARGET_CFG:=
   後ろには Tornado/VxWorks のバージョンに応じて次のいずれかを指定します。
   WR_egcs_simnt_VxWorks5_4.mk または WR_gcc2_9_simnt_VxWorks5_5.mk  

次の変数をコマンドラインで使用することもできます。

• OUT_DIR 変数  
• CPPTEST_INC_DIR 変数 (別のソースからビルドする場合)  

例: Tornado プロジェクト/ワークスペースを使用する

C++test で提供されている Tornado プロジェクトまたはワークスペースからランライム ライブラリをビルドするには、次の操作を行います・

1. C++test_install_dir/engine/runtime/projects に移動します。  
2. プロジェクトまたはワークスペースを開きます。 Tornado/VxWorks のバージョンに応じて Tornado2_0 または Tornado2_2 を選択します。  
3. 開いた C++testRtLib プロジェクトをビルドします。  

C++test_install_dir/engine/runtime/target にある .mk ターゲット コンフィギュレーションをコピーまたは編集して、TARGET_CFG 引数に指定することができます。Tornado に別のビルド ターゲットを追加して、ビルド オプションやターゲットを変更できます。

外部 VxWorks イメージ シンボル リストの生成

外部シンボル リストは、 [未解決シンボルが検出された場合は実行を中断する] オプションが有効になっているテスト コンフィギュレーションを使って VxWorks テスト オブジェクトをビルドするために必要です。Tornado 関連のビルトイン テスト コンフィギュレーションでは [未解決シンボルが検出された場合は実行を中断する] オプションが有効になっています。外部シンボル リストは、アプリケーションの実行に使用する VxWorks カーネル イメージで定義されたすべてのシンボルを含むべきです。

次の操作を行って VxWorks イメージ シンボル リストを生成できます。

1. 必要な Tornado 環境変数が正しく設定されていることを確認します。詳細については 「要件」を参照してください。  
2. [Embedded Systems] > [Wind River] > [Extract Symbols from VxWorks Image] テスト コンフィギュレーションを複製します。  
3. [実行] タブを開きます。  
4. Symbols listing tool name テスト フロー プロパティに、イメージを作成したコンパイラに適したシンボル ダンプ ツールの名前を設定します。たとえば ccsimpc の場合は、nmsimpc を指定します。  
5. 必要があれば Symbols listing options を変更します。  
6. Path to a VxWorks image to scan for symbols テスト フロー プロパティに、 VxWorks イメージへのパスを設定します。例:
   "%WIND_BASE%\target\config\simpc\vxWorks"  
7. 複製したコンフィギュレーションを実行します。  

外部シンボル リストの詳細については、「外部シンボル リストの作成」を参照してください。

テスト オブジェクトの実行

ここで言う「テスト オブジェクト」とは、ソース ファイルとテスト スイートから生成される最終的な成果物を指し、これは、テスト ケースの結果やカバレッジ データといった実行時データを収集するために実行する必要があります。本ユーザーズ ガイドの別のセクションでは、「テスト オブジェクト」の代わりに「テスト用実行モジュール」という用語を使用しています。組込み開発のセクションで異なる用語を使う理由は、組込みシステムは必ずしも「実行モジュール」をサポートしないからです。この「実行モジュール」とはすなわち、アプリケーション イメージと呼ぶことができるバイナリ ファイルであり、システム自体がロード (アンパック) して実行できるバイナリ ファイルです。たとえば VxWorks 5.4 および VxWorks 5.5 の場合、アプリケーションのプロシージャにリンクする完全なシステム イメージをビルドできるほか、アプリケーションのシンボルだけを含み、後でビルド済みのシステム イメージにリンクされる、不完全な再配置可能オブジェクトをビルドできます。Tornado による VxWorks のテストの場合、C++test は、最も良く表現するとして「再配置可能テスト」と呼ぶことができる 2 番目のタイプのオブジェクトをビルドして、Tornado Shell (windsh) というオリジナルの Tornado ツールを使って実行しようとします。実行時テストを開始する前に、Tornado Registry (wtxregd) および Target Server (tgtsvr) が起動していてターゲットの実行中の VxWorks に接続している必要があります ( 「要件」を参照).

たとえば、 VxWorks シミュレーターでのテストのためにテスト環境を準備するには、 次の操作を行います。この操作説明は、「要件」にあるように、必要な Tornado 環境変数が正しく設定済みであることを前提とします。オリジナルの Tornado インターフェイスを使用するか、次の例に示す手順およびコマンドを実行します。

1. 自分の UID を WIND_UID 環境変数に設定します。WIND_UID の詳細については『Tornado User's Guide』を参照してください。  
2. Tornado レジストリを起動します。
   wtxregd & '  
3. VxSim を起動します。
   "%WIND_BASE%\target\config\simpc\vxWorks" &  
4. ターゲット サーバーを起動します。
   tgtsvr vxsim -B wdbpipe -R "C:\Temp" -RW &  

デフォルトの Tornado に付属の VxSim は、 Pass Through File System (PassFS) および Target Server File System (TSFS) のサポートが構成済みです。このサポートおよび上記の設定によって、テスト オブジェクトはデフォルトのランタイム ライブラリにファイル通信でリンクすることができ、いずれかのファイル システムを使って結果を転送できます。 (ランタイム ライブラリについては 「ランタイム ライブラリのビルド」を参照してください。)

Tornado ツールおよび VxWorks の詳細については、Tornado のマニュアルを参照してください。

Tornado テスト コンフィギュレーション

Tornado プロジェクトのテストに特化したテスト コンフィギュレーションとして、[ビルトイン] > [Embedded Systems] > [Wind River] > [Tornado] の下に次のテスト コンフィギュレーションが用意されています。

• Build VxWorksTest Object (PassFS)  
• Build VxWorksTest Object (Socket)  
• Build VxWorks Test Object (TSFS)  
• Load and Run VxWorks Test Object  
• Load and Run VxWorks Test Object (Socket)  
• Run VxWorks Unit Tests (PassFS)  
• Run VxWorks Application with Mem Monitoring (PassFS)  
  
  

これらのテスト コンフィギュレーションは、特別に設計された次のテスト実行フローをベースにしています ( 「テスト実行フローによるテスト コンフィギュレーションのカスタマイズ」を参照してください)。

• Build VxWorks test object - File Channel on PassFS
  (WRTornadoBuildVxWorksPassFS.recipe)  
• Build VxWorks test object - Socket Channel
  (WRTornadoBuildVxWorksSocket.recipe)  
• Build VxWorks test object - File Channel on TSFS
  (WRTornadoBuildVxWorksTSFS.recipe)  
• Load and run VxWorks test object using Wind River Shell
  (WRTornadoLoadAndRun.recipe)  
• Load and run VxWorks Test Object using Wind River Shell - Socket Comm
  (WRTornadoLoadAndRunSocket.recipe)  
• Run unit tests on VxWorks - File Channel on PassFS
  (WRTornadoVxWorksPassFSFull.recipe)  
• Run application on VxWorks - File Channel on PassFS
  (WRTornadoVxWorksPassFSApp.recipe)  

上記のテスト コンフィギュレーションおよびテスト フローで使用される用語について簡単に説明します。

• Build これらのテスト コンフィギュレーションは、テスト オブジェクトをビルドします。これには静的カバレッジ データの生成と読み込みも含まれますが (カバレッジが有効な場合)、テスト オブジェクトの起動または結果の読み込みは含まれません。  
• Load and run テスト コンフィギュレーションは、 Wind River Shell を使ってテスト オブジェクトを起動します (テスト オブジェクトの実行の詳細については 「テスト オブジェクトの実行」 を参照してください)。ソケット用のコンフィギュレーションは、socket listner というツールを使用して、テストを実行するマシンから結果データのストリームを取得します。  
• Run これらのテスト コンフィギュレーションは、オール イン ワンのテスト コンフィギュレーションであり、テスト オブジェクトのビルド、テスト オブジェクトの起動、および結果の読み取りを行います。現在のところ、VxSim 用のコンフィギュレーションが用意されています。  
• PassFS これらのテスト コンフィギュレーションは、結果を処理するためにパス スルー ファイル システムを使用します。このファイル システムは VxSim でのみ利用可能です。VxSim は通常のホスト アプリケーションであるため、通常のホストのファイル入出力を提供します。デフォルトの [ビルトイン] > [Utilities] > [Load Test Results (File)] テスト コンフィギュレーションを使って、 そのようなテスト オブジェクトからの結果を読むことができます。
• TSFS これらのテスト コンフィギュレーションは、ターゲット サーバー ファイル システムを使用します。つまり、ターゲットのファイル入出力リクエストを処理してリクエストをホストに送ることができます。TSFS の利点は、VxSim と「実際の」ターゲットの両方で TSFS を利用できることです。 ただし、アプリケーションの実行に使用する VxWorks イメージで、TSFS コンポーネントを有効にし、初期化しなければなりません。またターゲット サーバーがホストの FS にアクセスできるよう、ターゲット サーバーを構成して読み取り/書き込み可能なディレクトリを指定する必要があります。TSFS を利用するテスト オブジェクトが生成した結果は、このディレクトリに格納されます。結果を読むには、[Load Test Results - File] テスト コンフィギュレーションを複製し、適切な結果ログ ファイルを指すようにテスト実行フローを調整する必要があります。詳細については 「テスト実行フローによるテスト コンフィギュレーションのカスタマイズ」を参照してください。  
• Socket これらのテスト コンフィギュレーションは、ネットワーク ソケットを使用してターゲットとホストの間でテスト結果をストリーム転送します。結果を受け取るには特別なリスナーを使用します。アプリケーションの実行に使用する VxWorks イメージで、ネットワークおよびソケット コンポーネントを有効にし、初期化しなければなりません。[Load Test Results (File)] テスト コンフィギュレーションを使って、結果を読むことができます。  
• Application これらのテスト コンフィギュレーションは、単体テストを実行する代わりに、デフォルトのエントリ ポイントを使用してアプリケーション モードでアプリケーションを実行します。  
• Mem Monitoring これらのテスト コンフィギュレーションは、テスト対象アプリケーションのメモリ解析を行います。C++test で実行時エラー検出を行うための全般的な情報については、 「実行時エラー検出」を参照してください。  

その他、必要となる可能性のあるビルトイン コンフィギュレーションは次のとおりです。

• [Unit Testing] > [Generate Unit Tests]  
• [Utilities] > [Generate Stubs Using External Library Symbols] [Unit Testing] > [Generate Stubs] ではなく、このコンフィギュレーションを使用してください。  
• [Embedded Systems] > [Wind River] > [Extract Symbols from VxWorks Image]  

テスト コンフィギュレーションの詳細については、「テストコンフィギュレーションとルールの設定」を参照してください。

テスト実行フローによるテスト コンフィギュレーションのカスタマイズ

組込み開発者にとって、単体テスト プロセスの流れを知ること、そしてソース コードに C++test が適用する一連のツールを知ることは重要です。期待どおりに動作する堅牢なプロセスを構築するには、そのような知識が欠かせません。

テスト実行フローの多くの部分は、環境が異なっても同じであり、ほとんどの場合、フロー ステップの順序とパラメーターは変更するべきではありません。ただし特定の状況では、一部の重要なフロー ステップを調整する必要があります。テスト コンフィギュレーション マネージャーのエディターで、テスト実行フロー パラメーターをニーズに合わせて変更できます。ビルトイン テスト コンフィギュレーションでは、重要でよく変更されるフロー プロパティを簡単に変更できるため、通常はカスタム実行フローを作成する必要はありません。

テスト実行フローのカスタマイズ方法については 「テスト実行フローのカスタマイズ」を参照してください。

より高度なカスタマイズが必要になることがまれにあります。そのような場合、「カスタム テスト実行フローの定義 」 で説明されているように、カスタム テスト フローを定義できます。テスト フローをカスタマイズする必要がある場合、以下のヒントを参考にしてください。

• すべての通信モード (ファイル、ソケット、rs232) で、テスト終了時に結果データがホスト マシンに格納された実行時ログ ファイルという形でｓ存在していなければなりません。ログ ファイルはホスト側の C++test によって読み取られます。  
• ファイル通信モードでは、テスト オブジェクト自体が実行時ログ ファイルを生成します。ソケット/rs 通信モードでは、テスト オブジェクトからのデータ ストリームを受け取って保存するために、ホスト上でリスナーが実行されていなければなりません。  
• TSFS 通信は C++test 向けのファイル通信タイプです。I/O メカニズムはツールのスコープを超えています。  
• 次のステップをレビューおよび調整します。  
  • TestRunnerGenerationStep 実行時ログ ファイルのパス (ターゲットのビュー)、属性: testLogFile, covLogFile  
  • ReadTestLogStep テスト ログ ファイルへのパス (ホスト)、属性: testLogFile  
  • ReadDynamicCoverageStep カバレッジ ログ ファイルへのパス (ホスト)、属性: covLogFile  

テスト ケースのデバッグ

C++test はこの環境での直接的なテスト ケース デバッグをサポートしていません。

hostShell を使ってターゲット カーネルにテスト用実行モジュールをロードし、目的のテスト ケースに手動でブレークポイントを設定してください。