Rational® Developer 製品の自動化コンポーネント・テスト機能を使用すると、Java™ コンポーネント用、EJB 用、および Web サービス用の自動化されたテストを作成、編集、デプロイ、および実行できます。 これらの機能は、UML Testing Profile の標準に準拠しており、JUnit のテスト・フレームワークを使用します。
これらの機能を使用すると、以下のアクションを実行できます。
Rational Developer 製品を使用して作成するテストはすべて、JUnit テストの拡張です。 それに加え、既存の JUnit テストのインポート、編集、および実行が可能です。 自動化コンポーネント・テスト機能は、以下のプリミティブ・ファミリーを使用して JUnit を拡張します。
検証アクションとオリジナルの JUnit assert メソッドとの主な違いは、検証アクションの場合は失敗の表明が行われても JUnit テスト・スイート全体の実行は停止されないということです。
コンポーネントをテストするためには、最初にテスト・プロジェクトを作成する必要があります。
テスト・プロジェクトは、テストする必要のあるコンポーネントが含まれている 1 つ以上の開発プロジェクトとリンクされています。 開発プロジェクトとしては、Java 開発プロジェクト、エンタープライズ・アプリケーション・プロジェクト、または動的 Web プロジェクトが挙げられます。 各テストでターゲットとなるコンポーネントは、CUT (テスト対象コンポーネント) として知られています。
テスト・プロジェクトには、実行指向のエレメント (テスト・スイートおよびテスト実行) と、コード指向のエレメント (テスト振る舞いスクリプトおよびスタブ) が含まれています。 テスト・スイートとテスト実行は、「テスト・ナビゲーター」ビューで参照および編集できます。一方、テスト振る舞いスクリプトとスタブは、「パッケージ・エクスプローラー」ビューに表示されます。
テスト中には、CUT が相互作用するコンポーネントをスタブする必要が生じることがしばしばあります。 そうすることで、CUT を分離してテストできるため、テストしているのが確かに CUT であって、それ以外のコンポーネントではないことを確信できます。 テストと同様に、スタブは振る舞いとデータによって定義します。 スタブの振る舞いは、スタブのユーザー・コード・クラスに定義します。これは、「Java コード」ビューに表示して編集できます。 スタブ・データは、スタブ・データ・テーブルで提供されます。このテーブルにより、特定の入力に対するスタブ・クラスの出力の振る舞いが定義されます。 スタブ・データ・テーブルを使用し、それぞれのスタブ・メソッドごとに実際の入力値と戻り値を指定して、スタブ・クラスをシミュレートしてください。
スタブは、テストの作成時に行う CUT の分析を介して自動的に生成できます。
テスト・デプロイメントは、テストを実行する条件を指定するフェーズです。 主に EJB の場合は、テスト・デプロイメント・データにはアプリケーション・サーバー情報が含まれます。 テスト・スイート・エディターを使用して、CUT をデプロイするサーバー構成を選択してください。 サーバー構成は、サーバー・パースペクティブで定義します。
テスト・プロジェクトの任意のコンポーネント (テスト・スイート、テスト・ケース、または単一等価クラス) に対して起動構成を指定できます。これにより、テストをプロファイル・オプションまたはデバッグ・オプションを付けて、あるいは、付けないで実行できます。 テストの実行中には、テスト結果を取得できるようにデータ収集プログラムが CUT をモニターします。
テストを実行すると、テスト実行が生成されて、「テスト・ナビゲーター」ビューに表示されます。 テスト実行を展開すると、個々のテストとそれらについての判断 (成功、失敗、確定不能、またはエラー) が表示されます。 個々のテストから、「テスト・データ・コンパレーター」ビューに表示されている結果の詳細に移動すると、期待される結果と比較されている実際のテスト結果を確認できます。
テスト判断、テスト・データ、テスト・スイート、テスト振る舞いスクリプト、および CUT のコード内の関係のある部分の間でのコンテキスト・クロス・ナビゲーションが提供されます。
永続的なテスト環境を生成してセットアップすることの主な利点は、レグレッション・テストで手持ちのテストを容易に再利用できることです。 定期的なレグレッション・テストは、新しい欠陥が生じておらず、既存の欠陥は修正済みであることを確認するための信頼性の高い方法です。
開発プロジェクトの初期の段階でテストを作成しておくことは、有効な習慣です。製品仕様の解釈に役立ちます。 そのようにすると、コードを変更するたびに、またはコードを新しい環境に移すたびに発生する可能性のある、予期しないエラーを検出するために、開発過程で同じテストを定期的に実行できます。