SQL Developer: ユニット・テスト

4.1 ユニット・テストの概要

SQL Developerのユニット・テスト・フレームワークには、テスト・ケースごとに一連のステップがあります。ステップを実行する前のユーザー入力と、テスト実行の開始中に必要になるフレームワーク・アクティビティを含めて、次にステップを示します。

テストするオブジェクトを特定します。

ユーザー入力: 特定のPL/SQLプロシージャ、ファンクションなどのオブジェクトを識別します。

フレームワーク・アクティビティ: 処理するオブジェクトを選択します。
起動処理を実行します。

ユーザー入力: PL/SQLブロックを入力するか、起動処理がない場合はNULLを入力します。

フレームワーク・アクティビティ: ブロックを実行します。
ユニット・テストのオブジェクトを実行します。

ユーザー入力: (なし。)

フレームワーク・アクティビティ: ユニット・テストを実行します。
結果をチェックして記録します。

ユーザー入力: 予期したとおりに戻された値(結果)に加えて、検証ルールを識別します。

フレームワーク・アクティビティ: 結果を、検証も含めてチェックし、その結果を保存します。
終了処理(分解)を実行します。

ユーザー入力: PL/SQLブロックを入力するか、分解アクティビティがない場合はNULLを入力します。

フレームワーク・アクティビティ: ブロックを実行します。

テストごとに、前述のステップで求めた情報を入力して、テスト・ケースを作成します。ユニット・テストとは、特定のPL/SQLオブジェクト上の(1つまたは複数の)テスト・ケースのグループです。

各テスト・ケースが1つの実装になります。各ユニット・テストには1つ以上の実装(デフォルトの名前はDefault)があり、1つ以上の他の実装を追加することもできます。たとえば、様々なパラメータ値の組み合わせをテストする実装を、例外を生成する実装も含めて持つことができます。

ユニット・テストを実行すると、各実装が順に実行されます。各実装が、テストの起動アクション(存在する場合)、テスト実装自体、分解アクション(存在する場合)の順に実行します。実装間の相違点は、コール側の引数の値にあります。すべての実装の実行前に(起動アクション前を含む)、動的値問合せが評価されます。

複数のユニット・テストをテスト・スイートにまとめて、グループ化されたアイテムとして実行できるようにすると、指定したテスト・ケースおよびユニット・テストに加えて、そのテスト・スイート独自の起動処理と終了処理を設定できます。

SQL Developerを使用したユニット・テストの詳細を学習するには、必要に応じて次のいずれかのアプローチをとることができます。

「ユニット・テストの例(チュートリアル)」を参照してステップを実行してから、「SQL Developer: ユニット・テスト」に記載された概念説明に戻ってこれを読みます。

または
「SQL Developer: ユニット・テスト」に記載された概念説明を読んでから、最後に「ユニット・テストの例(チュートリアル)」を参照します。

関連項目

動的値問合せを使用したユニット・テストの作成

4.2 ユニット・テストに使用するSQL Developerユーザー・インタフェース

ユニット・テストのためのSQL Developerユーザー・インタフェースには、「ユニット・テスト」ナビゲータ、「ユニット・テスト」サブメニュー、およびその他の機能があります。

図4-1では、「ユニット・テスト」ナビゲータに、最上位のノードとして「ライブラリ」、「参照」、「レポート」、「スイート」および「テスト」が表示されています。(このナビゲータが表示されていない場合は、「表示」、「ユニット・テスト」の順にクリックします。)

図4-1「ユニット・テスト」ナビゲータ

「図4-1「ユニット・テスト」ナビゲータ」の説明

前の図では、最上位のリポジトリ・ノードに、使用される接続の名前(unit_test_repos)と、その接続に関連付けられているユーザーがそのリポジトリに対して「ユーザー」アクセスのみを持つか、「管理者」および「ユーザー」アクセスの両方を持つかが示されています(ここでは両方を持ちます)。

前述の図では、ライブラリ・ノードの下にアクションのタイプ(起動、分解、検証)、テスト・スイート1つ、および複数のテストが表示されています。

関連項目

4.2.1 「ユニット・テスト」サブメニュー

「ユニット・テスト」サブメニューを表示するには、「ツール」、「ユニット・テスト」の順にクリックします。(「ユニット・テスト」サブメニューのコマンドは、ユニット・テスト・リポジトリに適用されます。)

現在のリポジトリの選択: ユニット・テスト・リポジトリに使用するデータベース接続を選択し、関連するスキーマにリポジトリが存在しない場合は、この接続を使用するリポジトリを作成できます。

現行のリポジトリの選択解除: 現行のユニット・テスト・リポジトリの接続を解除します。ユニット・テスト・リポジトリ(同じリポジトリまたは別のリポジトリ)に再接続するには、「現在のリポジトリの選択」を使用します。

実行結果のパージ: 既存の結果をテストおよびスイートの実行から削除します。

リポジトリの作成/更新: ユニット・テスト・リポジトリを作成して、SQL Developerのユニット・テスト機能に関連するスキーマ・オブジェクトを保持できます。

リポジトリの削除: 現行のユニット・テスト・リポジトリを削除します。

リポジトリ・オブジェクトのパージ: 現行のユニット・テスト・リポジトリの内容を削除しますが、リポジトリのメタデータは削除しません。

ファイルからインポート:

ユーザーの管理: ユニット・テスト・リポジトリに使用するデータベース接続を選択、追加、および変更できます。

共有リポジトリを表示:

共有リポジトリとして選択: 現行のリポジトリを共有リポジトリにします。

共有リポジトリとして選択解除: 現行のリポジトリを共有されないリポジトリにします。

関連項目

ユニット・テスト・リポジトリ

4.2.2 その他のメニュー: ユニット・テストの項目

「表示」メニューには、ユニット・テストに関連する次の項目があります。

ユニット・テスト: 「ユニット・テスト」ナビゲータの表示を切り替えます。

4.2.3 ユニット・テストのプリファレンス

SQL Developerユーザー・プリファレンスのウィンドウ(「ツール」をクリックし、「プリファレンス」をクリックして表示)には、「ユニット・テストのパラメータ」ペインがあります。

関連項目

ユニット・テストのパラメータ

4.3 ユニット・テスト・リポジトリ

ユニット・テスト・リポジトリは、SQL Developerがユニット・テスト機能の使用を管理するために保持する、表、ビュー、索引、およびその他のスキーマ・オブジェクトの一連のセットです。(これらのオブジェクトのほとんどは、名前にUT_が付きます。)リポジトリに個別のデータベース・ユーザーを作成することも、既存のデータベース・ユーザーのスキーマを使用することもできますが、メインの共有リポジトリを1つ持つ環境の簡便さを考えると、個別のデータベース・ユーザーを作成することの方が多いと考えられます。

リポジトリは、様々なユニット・テスト操作の実行を許可するデータベース・ユーザーの数に応じて、共有または非共有に設定できます。

非共有リポジトリでは、そのユニット・テスト・リポジトリのスキーマ・オブジェクトを所有するデータベース・ユーザーのみを、リポジトリを変更する操作に使用できます。

たとえば、複数の非共有リポジトリを作成すると、個々の開発者はプライベートなリポジトリを作成できます。
共有リポジトリでは、リポジトリ・オブジェクトの所有者と、そのリポジトリへの管理者としてのアクセス権限(具体的には、UT_REPO_ADMINISTRATORロール)を付与された他のユーザーが、ユーザーの管理などの管理操作を実行できます。

共有リポジトリは最大で1つ作成でき、チーム開発の環境ではこれを使用することが一般的です。リポジトリ管理者は、ユーザーを追加し、リポジトリのステータスの共有と非共有を切り替えることができます。(リポジトリを共有にすると、SQL Developerは、該当するリポジトリ・オブジェクトにパブリック・シノニムを作成します。)

非共有リポジトリを共有に変更するには、「ツール」、「ユニット・テスト」、「リポジトリ」、「共有リポジトリとして選択」の順にクリックします。共有リポジトリを非共有に変更するには、「ツール」、「ユニット・テスト」、「リポジトリ」、「共有リポジトリとして選択解除」の順にクリックします。

関連項目

4.3.1 リポジトリのユーザーおよび管理者の管理

ユニット・テストおよびユニット・スイートを作成して実行するには、リポジトリにユーザーとしてアクセスする権限(具体的には、UT_REPO_USERロール)が付与されたデータベース・ユーザーの接続を使用する必要があります。ユーザーの管理などのリポジトリの管理操作を実行するには、リポジトリに管理者としてアクセスする権限(具体的には、UT_REPO_ADMINISTRATORロール)が付与されたデータベース・ユーザーの接続を使用する必要があります。

たとえば、ユーザーSCOTT、JONES、SMITHがユニット・テスト機能を使用できるように、共有リポジトリにユーザー権限でアクセスできるようにし、SYSとリポジトリ・オブジェクトの所有者のみが、この共有リポジトリに管理者権限でアクセスするとします。

データベース・ユーザーにいずれかのタイプのアクセス権を付与するには、「ツール」、「ユニット・テスト」、「リポジトリ」、「ユーザーの管理」の順にクリックします。リポジトリ・オブジェクトの所有者のデータベース接続、または管理者権限でのアクセス権を付与されたその他のユーザーを選択します。「ユニット・テスト: ユーザーの管理」ダイアログ・ボックスが表示されます。

関連項目

ユニット・テスト: ユーザーの管理

4.4 ユニット・テストの編集と実行

ユニット・テストを編集するには、「ユニット・テスト」ナビゲータでユニット・テスト名をクリックし、そのユニット・テストを実行するために必要な接続を選択します。ユニット・テストの仕様の詳細を示す「詳細」と、テストを実行またはデバッグした場合の結果を示す「結果」の、2つのタブのあるペインが表示されます。

「詳細」タブの下にあるツールバーには、次の図に示すアイコンを含むツールバーがあります。

図ut_edit_toolbar.gifの説明

「ビューの固定」(ピン)では、「ユニット・テスト」ナビゲータで別のユニット・テストをクリックしたときに、SQL Developerウィンドウ内のペインが保持され、別のユニット・テストには別のタブと詳細表示ペインが作成されます。ピンをもう一度クリックすると、ユニット・テストの詳細表示ペインを再利用できます。
「リフレッシュ」では、ペイン内の表示が更新されます。
「デバッグ」は、デバッグ・モードでユニット・テストの最初または次の実装を実行開始し、その結果を「結果」タブに表示します。
「実行」は、ユニット・テストの通常実行を開始して、「結果」タブに結果を表示します。(「実行」をクリックする前に、右側のデータベース接続を選択して、この実行操作を行うデータベース・ユーザーを指定できます。)
「編集」(鉛筆のアイコン)では、ユニット・テストの仕様を編集できます。(ユニット・テストを変更できない場合は、「「編集」アイコンをクリック。)
「変更のコミット」では、ユニット・テストに対する変更を保存します。
「変更のロールバック」は、ユニット・テストに対する変更を保存せず破棄します。

「編集」アイコンをクリックすると、起動処理、分解処理、および各実装の詳細を変更できます。

また、「コード・カバレッジ統計の収集」を指定すると、SQL Developerはコード・カバレッジに関連する統計が収集されます。ユニット・テスト実行から収集された統計を参照するには、「テスト実行のコード・カバレッジ」レポートを使用します。このレポートの「コード・カバレッジの詳細」ペインで、サマリー情報の行をクリックします。

関連項目

SQL Developer: ユニット・テスト

4.5 動的値問合せを使用したユニット・テストの作成

ユニット・テストを作成するときに、入力データを正確に指定するのではなく、テストの入力として表のデータを使用する動的値問合せを作成することができます。問合せによって1つ以上の行の指定した列から値が戻され、戻されたすべての値セットは、そのテストに指定した任意のプロセス検証によってチェックされます。動的値問合せの一般的な利用方法の1つに、テストの結果である給与または価格が指定した範囲内にあるかどうかをチェックするなどの「適正」テストがあります。

動的値問合せを使用するテストを作成するには、その問合せが使用する表を作成して値を入力し、テスト対象のオブジェクトと任意の起動および分解アクションを指定してテストを作成し、検証アクション(問合せが行を戻すかどうかなど)を指定します。

注意:

テスト内のすべての実装を実行する前に(テストの起動アクションを含めて)、動的値問合せを実行します。動的値問合せを評価する前に表に値を入力する必要がある場合は、そのテストを含むスイーツの起動アクションを実行できます。

次の例は、「ユニット・テストの例(チュートリアル)」で、少なくともEMPLOYEES表の作成、AWARD_BONUSプロシージャの作成、およびユニット・テスト・リポジトリの作成まで行っていることを前提とします。ここでは、給与金額が20000を超えるボーナスを受け取った販売員がいないことをチェックするユニット・テストを作成します。次のステップを実行します。

次の文を実行して、データの表を作成し、値を入力します。

CREATE TABLE award_bonus_dyn_query (emp_id NUMBER PRIMARY KEY, sales_amt NUMBER);
INSERT INTO award_bonus_dyn_query VALUES (1001, 5000);
INSERT INTO award_bonus_dyn_query VALUES (1002, 6000);
INSERT INTO award_bonus_dyn_query VALUES (1003, 2000);
commit;

「ユニット・テスト」ナビゲータで「テスト」ノードをクリックし、「テストの作成」を選択します。

「ユニット・テスト: ユニット・テストの作成」ウィザードが表示されます。「次へ」をクリックして、各ステップから次へと移動し、ユニット・テストの指定が終了したら「終了」をクリックします。
「操作の選択」で、AWARD_BONUSプロシージャの作成に使用したスキーマのデータベース接続を選択し、「プロシージャ」ノードを開いて「AWARD_BONUS」を選択します。
「テスト名の指定」で、「テスト名」にAWARD_BONUS_DYN_QUERY(作成済の表と同じ名前)を指定し、「単一のダミー表現を使用して作成します」を選択します。
「起動の指定」で、ユニット・テストでデータが変更される前にEMPLOYEES表の現在のデータ値を保存するため、「表または行のコピー」を選択します。

プロンプトが表示されたら、「ソース表」にEMPLOYEESを指定し、「ターゲット表」では、必要なときに自動的に作成され、不要になったら自動的に削除される一時表のデフォルトの名前を受け入れます。
「パラメータの指定」で、「次へ」をクリックして次のページに進みます。(この例では、ここでは「動的値問合せ」を指定せずに、後のステップで指定します。)
「検証の指定」で、「次へ」をクリックして次のページに進みます。
「分解の指定」で、ユニット・テストによってデータが変更される前にEMPLOYEES表の元のデータ値をリストアする必要があるため、「表または行のリストア」を選択します。プロンプトが表示されたら、「ターゲット表」および「ソース表」に表示される値(それぞれ、EMPLOYEESおよび一時表の名前)を受け入れます。
「サマリー」で、情報を確認します。変更が必要な場合は、「戻る」をクリックして必要な画面に戻って変更してから、この「サマリー」ページまで進みます。ユニット・テストの定義を終了できるようになったら、「終了」をクリックします。
「ユニット・テスト」ナビゲータで、「テスト」の下にあるノードの「AWARD_BONUS_DYN_QUERY」をクリックすると、編集ウィンドウにテストが表示されます。
「詳細」ペインで、動的値問合せの横にある鉛筆のアイコンをクリックし、次のとおりに入力して「OK」をクリックします。
```
SELECT emp_id, sales_amt FROM award_bonus_dyn_query;
```
「予期した結果」で、「成功」の値はそのままにします。
「検証の指定」で、プラス・アイコン(+)をクリックし、「問合せで返される行なし」を選択します。

問合せで、「プロセスの検証」ボックスのSELECT文を次の文に置換します(文の末尾にあるセミコロンは無視されます)。
```
SELECT * FROM employees WHERE salary_amt > 20000
  AND commission_pct IS NOT NULL
```
こうして、すべての販売員(歩合の割合がNullでないすべての従業員)に対して、ユニット・テスト実行の結果である給与が20000を超えているかどうかをチェックします。該当する販売員がない場合(問合せで行が戻されない場合)、検証アクションの結果は成功です。
AWARD_BONUS_DYN_QUERYユニット・テストを実行します。

関連項目

4.6 参照によるユニット・テストの作成の簡略化

参照とは、1つ以上のデータ型の、テスト可能なデータ値を含むオブジェクトです。参照は、主に次の目的で使用されます。

入力フィールドの値のリスト(ドロップダウン・リスト)の提供。
参照値に基づくテスト実装の自動作成。

参照を作成するには、次の手順を実行します。

「ユニット・テスト」ナビゲータで、「参照」ノードを右クリックし、「カテゴリの追加」を選択します。
カテゴリ名(EMP_ID_LOOKUPなど)を指定します。
参照値(テストが可能な有効および無効なデータ値)を指定するデータ型ごとに、カテゴリ名を右クリックし、「データ型の追加」を選択してデータ型を選択し、+(プラス記号)アイコンを使用して必要な数のデータ値を追加します。

(null)は、作成する各参照の各データ型の値のリストに自動的に含まれることに注意してください。

たとえば、「ユニット・テストの例(チュートリアル)」で説明する環境では、EMP_ID_LOOKUPおよびSALES_AMT_LOOKUPという名前の参照を作成します。それぞれデータ型NUMBERが1つだけ設定されています。各参照のNUMBERデータに、+(プラス記号)アイコンを使用して1行に1つずつ次の値を追加し、各参照に一連の数値を入力したら「変更のコミット」アイコンをクリックするかF11を押します。

EMP_ID_LOOKUPの場合: -100、99、1001、1002、1003、1004、2000、9999
SALES_AMT_LOOKUPの場合: -1000、0、1000、2000、5000、6000、10000、99999

「ユニット・テスト」ナビゲータのコンテキスト(右クリック)メニューを使用すると、参照カテゴリの削除や名前の変更ができます。参照カテゴリに設定したデータ型も削除できますが、この場合の「削除」とは、その参照カテゴリのデータ型に現在指定されているデータ値を削除することで、これによって「ユニット・テスト: データ型の追加」ダイアログ・ボックスで選択したデータ型を使用できるようになります。

関連項目

4.6.1 入力フィールドでの値の提供

ユニット・テスト実装に入力パラメータを指定するときに、「カテゴリの参照」コントロールをクリックして参照カテゴリを選択できます。その後、「入力」の下のセルをクリックして、下向き矢印をクリックすると指定した参照から値を選択できます。(リストから選択するのではなく、値を入力することもできます。)

たとえば、EMP_ID_LOOKUP参照カテゴリを作成して、パラメータを指定するときこれを参照カテゴリとして選択し、EMP_IDパラメータの「入力」セルのドロップダウンリストの値として、-100、99、1001、1002、1003、1004、2000、9999および(null)を表示させることができます。(SALES_AMTパラメータでは、SALES_AMT_LOOKUPカテゴリを使用します。)

関連項目

参照によるユニット・テストの作成の簡略化

4.6.2 実装の自動作成

あるデータ型の特定の値をテストするための実装が必要な場合、手動で作成するのではなく、参照カテゴリを使用して実装を自動生成できます。これを行うには、DEFAULT参照カテゴリまたはユーザーが作成したカテゴリを使用して必要なデータ型に値を指定し、この参照カテゴリを「ユニット・テストのパラメータ」プリファレンスの「参照に使用する構成セット」プリファレンスに指定します。

たとえば、NUMBER型の入力パラメータがあり、正の最大値(9999など)、負の最小値(-9999など)、1、-1、および0(ゼロ)を常にチェックする必要があるとします。次のステップを実行します。

「ユニット・テスト」ナビゲータで、「参照」ノードを開きます。
「DEFAULT」を右クリックして「データ型の追加」を選択します。
ダイアログ・ボックスで「NUMBER」を指定します。
NUMBER型の「参照エディタ」で、+(プラス記号)アイコンを使用して、次の各値を個別の項目として(1行に1つずつ)追加します。
```
9999
1.0
0
-1.0
-9999
```
「変更のコミット」アイコンをクリックするかF11を押します。
「Tools」、「Preferences」、「Unit Test Parameters」の順にクリックし、参照に使用する構成セットがDEFAULT(NUMBERデータ型の値を指定した参照カテゴリ)であることを確認します。
「ユニット・テスト」ナビゲータで「テスト」ノードを右クリックして「テストの作成」を選択するという通常の方法で、ユニット・テストを作成します。

ただし、「テスト名の指定」のステップでは、「参照値を使用して実装をシード/作成します。」(「単一のダミー実装を使用して作成します。」ではない)を指定します。

「起動の指定」および「分解の指定」で、必要なアクションを指定します。

この時点では「パラメータの指定」または「検証の指定」には何も指定できません。NUMBER型の入力パラメータの可能な組み合わせのそれぞれに、実装(Test Implementation nの形式の名前が付いたもの)が自動作成されます。何らかの検証アクションを実行するには、生成された各実装を編集して指定する必要があります。

関連項目

4.7 検証アクションでの変数置換の使用

検証アクションで変数置換を使用すると、プロシージャまたはファンクションの入力および出力パラメータの値、またはファンクションの戻り値に基づいた結果を提供する、動的な検証を記述できます。検証アクションでは、次の形式で文字列を指定できます。

入力パラメータの場合: {PARAMETER_NAME}

たとえば、入力パラメータの名前がEMP_IDの場合は、次のようになります。
```
SELECT ... WHERE employee_id = {EMP_ID} AND ...;
```
出力パラメータの場合: {PARAMETER_NAME$}

たとえば、出力パラメータの名前がSALARYの場合は、次のようになります。
```
SELECT ... WHERE {SALARY$} < old_salary;
```
戻り値の場合: {RETURNS$}

たとえば、ファンクションが数値を戻す場合は、次のようになります。
```
SELECT ... WHERE {RETURNS$} > 1;
```

実際に置換されるものは、パラメータ値の文字列表現(テキスト置換の場合)またはパラメータの基礎となるデータ値(構文: param-nameを使用したバインド置換の場合)です。次の例では、置換の両方のスタイル(テキスト・スタイルおよびバインド・スタイル)を示しています。

DECLARE
    l_PARAM1 DATE;
    bad_date EXCEPTION;
BEGIN
    l_PARAM1 := :PARAM1;
    IF '{PARAM1}' <> TO_CHAR(l_PARAM1)
    THEN
        RAISE bad_date;
    END IF;
END;

テキストスタイルの変数置換の例は次のとおりです。

P1がNUMBER型のパラメータで値が2.1である場合、文字列{P1}は文字列2.1に置換されます。
P1がVARCHAR2型のパラメータで値がABCである場合、文字列'{P1}'は文字列'ABC'に置換されます。(この例で、{P1}が一重引用符で囲まれていることに注意してください。)

変数置換は、「表の比較」以外のすべてのタイプの検証アクションで使用できます。適用可能な検証アクション・タイプである場合、変数置換は次のように実行されます。

「問合せで返される行」および「問合せで返される行なし」の場合、SQL問合せで置換が実行されます。
「問合せ結果の比較」の場合、ソースおよびターゲットのSQLクエリーで置換が実行されます。
「ブール関数」および「ユーザーPL/SQLコード」の場合、PL/SQLブロックで置換が実行されます。

4.8 ユニット・テストのライブラリ

ユニット・テストのライブラリを使用すると、アクションを保存して、複数のユニット・テストの定義で再利用できます。これらのユーザー定義アクションは、「ユニット・テスト」ナビゲータの「ライブラリ」ノードの下に表示されます。次のカテゴリのライブラリに、次の種類のアクションを保存できます。

動的値問合せ
起動アクション
分解アクション
検証アクション

ほとんどのカテゴリにはサブカテゴリがあります。たとえば、「起動」アクション・ノードには、サブノード「表または行のコピー」および「ユーザーPL/SQLコード」があります。ライブラリにエントリを追加する手順は、次のとおりです。

「ライブラリ」階層を開いて、関連する最下位レベルのノード(「起動」の下の「ユーザーPL/SQLコード」など)を表示し、右クリックして「[アクション・タイプ]の追加」を選択し、アクションの名前を指定して、新規作成したアクションの名前をクリックして指定を完了します。
ユニット・テストを作成するときにアクションを指定するには、「ライブラリに公開」オプションを使用して、アクションの名前を入力し「パブリッシュ」をクリックします。(このアクションは、「ユニット・テスト」ナビゲータに表示される「ライブラリ」の、適切なカテゴリおよびサブカテゴリの下に追加されます。)

ユニット・テストを作成したときにライブラリのアクションを使用するには、「ユニット・テスト: ユニット・テストの作成」ウィザードの適切なページで、またはユニット・テストの編集時に「ライブラリ」の下のリストから選択します。ライブラリからアクションを選択する際、アクションをプロセス(起動、分解または検証)に組み込むために、次のオプションを指定できます。

コピー: アクションのコピーを使用して、コピーを編集できます(ユーザーPL/SQLコード・プロシージャのWHERE句を編集する場合など)。後でライブラリでそのアクションを変更しても、変更後のアクションが自動的にプロセスに再コピーされることはありません。
サブスクライブ: ライブラリに格納されているアクションが使用されます。(「サブスクライブ」オプションを使用した場合、プロセス内でこのアクションを編集することはできません。)後でライブラリでそのアクションを変更した場合、その変更後バージョンが自動的にプロセスで使用されます。

関連項目

4.9 ユニット・テストのレポート

複数のSQL Developerレポートによって、ユニット・テストに関連する操作の情報が提供されます。これらのレポートは、「ユニット・テスト」ナビゲータの「レポート」ノードの下にリストされます。使用できるレポートには、次のものがあります。

すべてのスイート実行
テスト実装のすべての実行
すべてのテスト実行
スイート実行のコード・カバレッジ
スイート・テスト実装の実行
スイート・テスト実行
テスト実装の実行
テスト実行のコード・カバレッジ
ユーザー・テスト実行(ユーザーがグループ化したテスト実行)

ユニット・テストの各レポートの上部ペインには、各項目のサマリー情報行が含まれています。いずれかの項目の詳細情報を参照するには、その行をクリックすると、サマリー情報の下にある1つ以上の詳細ペインに情報が表示されます。たとえば、「すべてのテスト実行」レポートのサマリー行をクリックすると、「テスト実行の詳細」および「最新のコード・カバレッジ」タブの下に、そのテスト実行の詳細が表示されます。

一部のレポートでは、バインド変数のプロンプトが表示されるので、デフォルト値を受け入れて関連するすべての項目を表示するか、またはバインド変数を入力して表示される項目を制限できます。

関連項目

4.10 ユニット・テストのオブジェクトのエクスポートおよびインポート

ライブラリ(起動アクション、検証アクション、分解アクションなど)に保存したユニット・テスト、スイート、およびオブジェクトをエクスポートおよびインポートできます。

オブジェクトをエクスポートすると、すべての依存オブジェクトが結果のXMLファイルに含まれます。たとえば、スイートをエクスポートすると、スイートに含まれるすべてのテストと、スイートの各テスト内の起動、検証、分解の各アクションが結果のXMLファイルに含まれます。

オブジェクトをエクスポートするには、「ユニット・テスト」ナビゲータでオブジェクトの名前を右クリックし、「ファイルにエクスポート」を選択して、オブジェクトの定義を含めるXMLファイルの場所と名前を指定します。

ユニット・テストのオブジェクトをXMLファイルからインポートすると、「ユニット・テスト」ナビゲータ階層の適切な場所に、ファイル内のすべてのオブジェクトが作成されます。XMLファイル内のオブジェクトと同じ名前で同じタイプのオブジェクトがリポジトリ内に既に存在する場合は、XMLファイル内のオブジェクトで置換(上書き)されます。

ユニット・テストのオブジェクトをインポートするには、「ツール」、「ユニット・テスト」、「ファイルからインポート」の順にクリックして、インポート操作に使用するXMLファイルを指定します。

関連項目

SQL Developer: ユニット・テスト

4.11 ユニット・テストのコマンドライン・インタフェース

ユニット・テストおよびスイートの実行とユニット・テスト・オブジェクトのエクスポートおよびインポートには、SQL Developerグラフィカル・インタフェースのかわりに、コマンドラインを使用することもできます。

コマンドライン・インタフェースからユニット・テストを実行する場合は、次のパラメータを使用できます。

-db <connection name>には、ユニット・テストの実行に使用するデータベース・ユーザーに関連付けられているデータベース接続を指定します。
-repo <connection name>には、ユニット・テストの実行に使用するユニット・テスト・リポジトリに関連付けられているデータベース接続を指定します。
{-log <0,1,2,3>}には、次に示すロギング・レベルを指定します。

0 = ロギングなし(デフォルト)。

1 = ステータスのレポート。

2 = ステータスおよびエラー・メッセージのレポート。

3 = ステータス、エラー・メッセージおよび戻りID値のレポート。
{-return <return id>}には、戻りID値を指定します(結果表の主キーとして使用され、自動ツールがデータベースからの結果を問い合せることができるようになります)。

次の例では、C:\の下にSQL DeveloperをインストールしたWindows環境で、AWARD_BONUSという名前のユニット・テストを実行しています。(コマンドライン・インタフェースでは、テストおよびスイートの名前で大文字と小文字が区別されることに注意してください。)この例では、ユーザーunit_test_reposのリポジトリ接続を使用し、ユーザーfredでテストを実行しています。

> cd c:\sqldeveloper\sqldeveloper\bin
> sdcli unittest -run -test -name AWARD_BONUS -repo unit_test_repos -db fred

次の例では、AWARD_BONUSという名前のユニット・テストをエクスポートしています。ユーザーunit_test_reposのリポジトリ接続を使用し、エクスポートした定義をファイルC:\ut_xml\award_bonus_test.xmlに保存しています。

> sdcli unittest -exp -test -name AWARD_BONUS -repo unit_test_repos -file c:\ut_xml\award_bonus_test.xml

次の例では、ファイルC:\ut_xml\award_bonus_suite.xmlからオブジェクト定義をインポートしています。ユーザーunit_test_reposのリポジトリ接続を使用しています。

> sdcli unittest -imp -repo unit_test_repos -file c:\ut_xml\award_bonus_suite.xml

コマンドラインから実行したテストまたはスイートの結果をチェックするには、SQL Developerを起動して「すべてのテスト実行」および「すべてのスイート実行」レポートを参照します。

関連項目

4.12 ユニット・テストのベスト・プラクティス

この項では、SQL Developerにおいてユニット・テストを使用する際の推奨事項および提案について説明します。

4.12.1 方針

パッケージが多数ある場合は、システム全体を分析してパッケージを機能領域別にグループ化し、各機能領域ごとにテスト・スイートを作成します。この機能分割処理は、再帰的に行うことができます(その場合は、共通の引数値セットを持つ、テスト可能なオブジェクトから成る小規模なグループを準備するのが理想的です)。

テスト・スイートの階層が準備できれば、各オブジェクト用のテストを作成して、それらをこの階層内に配置できます。

4.12.2 テスト・スイート

テストの一括実行を容易にするために、テストをテスト・スイートに編成する必要があります。

スイートは、他のスイートやテストから作成でき、関心のある領域を1つのグループにすることができます(すべてのテストを実行するスーパー・スイートを作成することも可能です)。

4.12.3 テスト名

テスト名は120バイトに制限されるため、シングルバイト文字セットでは最大120文字までです(マルチバイト文字セットでは、それよりかなり短くなります)。

テストは、テスト・オブジェクトの正式名を自動的に使用して作成されます(つまり、パッケージ・ファンクションおよびプロシージャが、パッケージ名で修飾されます)。たとえば、スタンドアロン・ファンクションまたはプロシージャの名前が、MY_PROCEDURE_NAMEおよびMY_FUNCTION_NAMEで、パッケージ名がMY_PACKAGE_NAMEの場合、テスト名はMY_PACKAGE_NAME.MY_PROCEDURE_NAMEおよびMY_PACKAGE_NAME.MY_FUNCTION_NAMEとなります。

4.12.4 テスト名の競合の回避

既存のテストと同名のテストを作成しようとした場合(たとえば、同じオブジェクトまたは別のスキーマの同名のオブジェクトで、テストを複数回作成した場合など)、新しいテスト名に連番が付加されます。その結果は、たとえば次のようになります。

MY_PACKAGE_NAME.MY_PROCEDURE_NAME
MY_PACKAGE_NAME.MY_PROCEDURE_NAME_1
MY_PACKAGE_NAME.MY_PROCEDURE_NAME_2

ただし、次のような代替方法も検討してください。

同名のオブジェクトが、別のスキーマに存在する場合は、テスト名の前に物理スキーマ名または論理シノニムを接頭辞にする(付加する)ことをお薦めします。たとえば、次のフル・テスト名の場合、最後の部分は同じですが、先頭が別のスキーマ名で始まっています。
```
USER3.MY_PACKAGE_NAME.MY_PROCEDURE_NAME
USER4.MY_PACKAGE_NAME.MY_PROCEDURE_NAME
USER5.MY_PACKAGE_NAME.MY_PROCEDURE_NAME
```
妥当な理由で同じオブジェクトにテストを複数回追加する場合は、デフォルトの連番方式を使用するかわりに、各テストに別個の名前を付ける方がよい場合があります。次に例を示します。
```
MY_PACKAGE_NAME.MY_PROCEDURE_NAME#LATEST
MY_PACKAGE_NAME.MY_PROCEDURE_NAME#COMPATIBLE
```

4.12.5 テスト実装

テストの作成時には、テストの子実装も作成されます。各実装で、テスト実行用の構成が形成されます。最初の実装は、Test Implementation 1と名付けられます。追加の実装を作成して、異なる値と環境の組合せでオブジェクトを実行できます。

テストの戦略を反映した実装名の使用をお薦めします。たとえば、Test Implementation 1、Test Implementation 2、Test Implementation 3という名前のかわりにUpper Boundaries、Lower Boundaries、Default Valuesなどの名前を使用します。

4.12.6 ライブラリ

ライブラリは、よく使用される値のリポジトリです(ただし参照を使用する必要のあるデータ値ではありません)。ユニット・テスト・パネルに同じ値を入力する必要がある場合(起動プロセスなど)は、その値をライブラリに保存して、複数箇所で再利用できます。

これをもう一段階進めて、再利用するかどうかに関係なく、すべての値をライブラリに保存することもできます。こうすると、テストの作成過程をより秩序立てることができ、テストのロジックが変更になった際に、それに応じてすべてのテストを容易に更新できます。

4.12.7 参照

参照には、カテゴリに編成した、データ型の値ドメインが格納されます。たとえば、売上カテゴリには、ドメイン値(-1, 0, 1, 1000, 1000000000)の数値データ型などが格納される場合があります。

細かい粒度(たとえば、EMPLOYEEまたはSET_3)で、または最大粒度(たとえばデフォルト)で、データ型値をグループ化するようなカテゴリを作成できます。

テスト実装は、1つの参照カテゴリにのみ関連付けられるため、あるカテゴリに、単一のテストのすべての実装で使用される値を含めることができます(その場合は、参照名に、対応するテスト名を反映させることをお薦めします)。

4.12.8 テストおよびスイートの実行

テストおよびテスト・スイートは、SQL Developerのグラフィック・インタフェースおよびコマンドライン・インタフェースを使用して実行できます。スイートまたは(すべてのテストが含まれる)スーパー・スイートを実行する場合は、コマンドライン・インタフェースを使用する方が便利な場合があります。

リポジトリ・スキーマ(または共有リポジトリのパブリック・シノニム)にあるUT_TESTおよびUT_SUITE表に対して実行されるジェネレータを作成して、テストおよびスイートの実行に必要なオペレーティング・システム・コマンドを生成できます。

4.12.9 レポート

ユニット・テスト・ナビゲータには、テストの実行結果を表示する、一連の事前定義済レポートが含まれます。

また、レポートを実行してグリッドを右クリックし、「グリッドをレポートとして保存」を選択してからレポートを表示して、ユニット・テスト表がどのように問合せに組み込まれているかを確認することもできます。

4.13 ユニット・テストの例(チュートリアル)

この項では、表およびPL/SQLプロシージャの作成、有効および無効な入力データのテスト・ケースを使用したユニット・テストの作成、ユニット・テストの実行、ユニット・テスト・スイートの作成および実行を行う簡単な例を示します。この例では、給与情報を含む従業員データの表があり、給与が基本給と歩合ベースのボーナスで構成される販売員のボーナスを計算するプロシージャを作成する必要があると仮定します。

EMPLOYEESには次の列が含まれており、これらはすべてNUMBER型です。

EMPLOYEE_ID: 従業員の識別(バッジ)番号。
COMMISSION_PCT: 従業員の歩合の割合: 従業員ごとの売上金額に対する割合を小数点表記したもので、従業員の基本給に加算するボーナスを算出して給与合計を決定するために使用されます。たとえば、0.2または.2は20パーセントの歩合で、売上金額の0.2倍であることを示します。

数値のCOMMISSION_PCT値はSales部門に所属する従業員のみに設定されます。その他の(「歩合制」ではない)従業員のCOMMISSION_PCT値はNullです。
SALARY: 従業員の給与の金額で、基本給に、(この例の中で作成するaward_bonusプロシージャによって計算される)ボーナスを加算したものです。

EMPLOYEES表のこれらの列には、次のデータがあるとします。

EMPLOYEE_ID	COMMISSION_PCT	SALARY
1001	0.2	8400
1002	0.25	6000
1003	0.3	5000
1004	(null)	10000

次の2つの入力パラメータを持つ、AWARD_BONUSというプロシージャを作成します。

emp_id: 従業員の従業員ID。
sales_amt: 対象となる期間中にその従業員が計上した売上金額。

この金額は指定された従業員のCOMMISSION_PCT値によって計算され、計算結果がその従業員のSALARY値に加算されます。

COMMISSION_PCTがNullの従業員の歩合(ボーナス)は計算されず、例外が発生します。このシナリオは、Sales部門以外の従業員の給与に歩合ベースのボーナスを追加しようとして発生します。

この例の以降の説明では、主要なステップを示します。

4.13.1 EMPLOYEES表の作成

このチュートリアルではEMPLOYEESという表を使用するため、AWARD_BONUSプロシージャのユニット・テストを実行する前に、この表が存在している必要があります。この表には、Oracle提供のサンプル・スキーマに含まれているHR.EMPLOYEES表と同じ列がいくつか含まれていますが、すべての列が含まれているのではなく、また行数も少なく、データも異なります。

このEMPLOYEES表を既存のスキーマに作成して既存のデータベース接続を使用するか、またはこの表のための新しいスキーマと接続を作成することもできます。表を作成してデータを入力するには、SQLワークシートまたはSQL*Plusのコマンド・ウィンドウで次の文を入力します。

-- Connect as the database user that will be used to run the unit tests.
-- Then, enter the following statements:
 
CREATE TABLE employees (employee_id NUMBER PRIMARY KEY, commission_pct NUMBER, salary NUMBER);
INSERT INTO employees VALUES (1001, 0.2, 8400);
INSERT INTO employees VALUES (1002, 0.25, 6000);
INSERT INTO employees VALUES (1003, 0.3, 5000);
-- Next employee is not in the Sales department, thus is not on commission.
INSERT INTO employees VALUES (1004, null, 10000);
commit;

4.13.2 AWARD_BONUSプロシージャの作成

EMPLOYEES表と同じスキーマにAWARD_BONUSプロシージャを作成します。SQLワークシートで適切なデータベース接続を使用して、次のテキストを入力します。

create or replace
PROCEDURE award_bonus (
  emp_id NUMBER, sales_amt NUMBER) AS
  commission    REAL;
  comm_missing  EXCEPTION;
BEGIN
  SELECT commission_pct INTO commission
    FROM employees
      WHERE employee_id = emp_id;
 
  IF commission IS NULL THEN
    RAISE comm_missing;
  ELSE
    UPDATE employees
      SET salary = salary + sales_amt*commission
        WHERE employee_id = emp_id;
  END IF;
END award_bonus;
/

「スクリプトの実行」アイコンをクリックして(またはF5を押して)AWARD_BONUSプロシージャを作成します。

4.13.3 ユニット・テスト・リポジトリの作成

作成してSQL Developerで維持するスキーマ・オブジェクトを保持するために、データベースにユニット・テスト・リポジトリが必要になります。このリポジトリ用に別のデータベース・ユーザーを作成することも、既存のデータベース・ユーザーのスキーマを使用することもできますが、学習手順と、後で必要になる可能性のあるデバッグ手順を簡単にするために、ユニット・テスト・リポジトリ用に別のスキーマを作成することをお薦めし、この項の手順でもこのアプローチを反映します。

ユニット・テスト・リポジトリのデータベース・ユーザー(UNIT_TEST_REPOSなど)を作成します。DBA権限のあるデータベース接続を使用して、「接続」ナビゲータの「他のユーザー」をクリックし、「ユーザーの作成」を選択します。ユーザー名にUNIT_TEST_REPOSを指定し、他の必要な情報をすべて入力します。

「デフォルト表領域」にUSERSを指定し、「一時表領域」にTEMPを指定します。

「システム権限」でCREATE SESSIONを有効にし、「適用」、「閉じる」の順にクリックします。
作成したユニット・テスト・リポジトリ・ユーザーに対するデータベース接続を作成します。「ツール」、「ユニット・テスト」、「ユーザーの管理」の順にクリックします。「接続の選択」ダイアログ・ボックスで、プラス記号(+)アイコンをクリックして、ユニット・テスト・リポジトリ・ユーザーに対する新規データベース接続を作成します(unit_test_reposなど)。

「保存」をクリックして接続を保存し、「取消」をクリックしてダイアログ・ボックスを閉じます。
作成したユーザーのスキーマにリポジトリを作成します。「ツール」、「ユニット・テスト」、「現在のリポジトリの選択」の順にクリックします。ユニット・テスト・リポジトリ・ユーザーに対するデータベース接続(unit_test_reposなど)を指定します。その接続にリポジトリが存在しないことを示すメッセージが表示された場合は、プロンプトに従って新規リポジトリを作成します。

SQL Developerによっていくつかのプロンプトが表示され、ユニット・テスト・リポジトリ・ユーザーに必要な権限を付与するコマンドを実行できます。それぞれに「はい」をクリックし、パスワードのプロンプトにSYSアカウントのパスワードを入力します。

4.13.4 ユニット・テストの作成

最初のユニット・テストを作成するには、「ユニット・テスト」ナビゲータを使用します。左側にこのナビゲータが表示されていない場合は、「表示」をクリックして「ユニット・テスト」をクリックします。

「ユニット・テスト」ナビゲータで「テスト」ノードをクリックし、「テストの作成」を選択します。

「ユニット・テスト: ユニット・テストの作成」ウィザードが表示されます。それ以降のステップで「次へ」をクリックして、各ステップから次へと移動し、ユニット・テストの指定が終了したら「終了」をクリックします。
「操作の選択」で、AWARD_BONUSプロシージャの作成に使用したスキーマのデータベース接続を選択し、「プロシージャ」ノードを開いて「AWARD_BONUS」を選択します。
「テスト名の指定」で、「テスト名」にAWARD_BONUS(プロシージャと同じ名前)を指定し、「単一のダミー実装を使用して作成します。」を選択します。
「起動の指定」で、プラス記号(+)アイコンをクリックして起動アクションを追加し、このアクションに対して「表または行のコピー」を選択します(ユニット・テストでデータが変更される前にEMPLOYEES表の現在のデータ値を保存するため)。

プロンプトが表示されたら、「ソース表」にEMPLOYEESを指定し、「ターゲット表」では、必要なときに自動的に作成され、不要になったら自動的に削除される一時表のデフォルトの名前を受け入れます。(ターゲット表が作成され、ターゲット表に指定した名前の表がすでに存在する場合は、既存の表が上書きされます。)
「パラメータの指定」で、Input列の値を次のように変更します。

EMP_IDパラメータの場合: 1001

SALES_AMTパラメータの場合: 5000

「予期した結果」で、「成功」の値はそのままにします。
「検証の指定」で、プラス・アイコン(+)をクリックし、「問合せで返される行」を選択します。

問合せで、「プロセスの検証」ボックスのSELECT文を次の文に置換します(文の末尾にあるセミコロンは無視されます)。
```
SELECT * FROM employees
  WHERE employee_id = 1001 AND salary = 9400
```
従業員1001の歩合は20パーセント(0.2)で売上金額は5000と指定されているため、ボーナスは1000(5000 * 0.2)で、この従業員の給与は最終的に9400(基本給8400にボーナス1000を加算)になります。ここでは、問合せが1行の結果を戻すため、検証アクションの結果は成功です。

このステップでは、次のように、変数置換を使用したSELECT文を指定することもできます。
```
SELECT * FROM employees
  WHERE employee_id = {EMP_ID} AND salary = 9400
```
ただし、この例のシナリオでは、変数置換を使用しても大きなメリットはありません。
「分解の指定」で、ユニット・テストによってデータが変更される前にEMPLOYEES表の元のデータ値をリストアする必要があるため、「表または行のリストア」を選択します。プロンプトが表示されたら、「ターゲット表」および「ソース表」に表示される値(それぞれ、EMPLOYEESおよび一時表の名前)を受け入れます。
「サマリー」で、情報を確認します。変更が必要な場合は、「戻る」をクリックして必要な画面に戻って変更してから、この「サマリー」ページまで進みます。ユニット・テストの定義を終了できるようになったら、「終了」をクリックします。

関連項目

4.13.5 ユニット・テストの実行

ユニット・テストを実行するには、「ユニット・テスト」ナビゲータを使用します。左側にこのナビゲータが表示されていない場合は、「表示」をクリックして「ユニット・テスト」をクリックします。

「ユニット・テスト」ナビゲータで「テスト」ノードを開いて「AWARD_BONUS」テストをクリックします。

「詳細」および「結果」のタブがあるAWARD_BONUSテストのペインが表示されます。
「詳細」タブの右上近くで、AWARD_BONUSプロシージャの作成に使用したスキーマのデータベース接続を選択します。

これ以外の値は変更しないでください。(ただし、後で別の指定またはデータ値を使用してユニット・テストを実行する必要が生じた場合は、ペイン上部の「コード・エディタ」ツールバーの「編集」(鉛筆)アイコンをクリックして変更できます。)
「コード・エディタ」ツールバーの「テストの実行」(緑色の矢印)アイコンをクリックします(またはF9を押します)。

ここで「結果」タブにフォーカスが移り、AWARD_BONUSが正常に実行されたことをすぐ確認できます。

EMPLOYEES表のデータをチェックすると、従業員1001の給与は以前と同じ(8400)ですが、これは、このユニット・テストの起動アクションが元のデータを一時表にコピーし、分解アクションがEMPLOYEES表に元のデータをリストアしたためです。

関連項目

ユニット・テストに使用するSQL Developerユーザー・インタフェース

4.13.6 例外ユニット・テストの作成と実行

別のユニット・テストを作成して、COMMISSSION_PCT値がNullで、歩合(ボーナス)の計算ができない従業員のための例外処理を作成します。このチュートリアルでは、テスト・データの従業員1004の歩合の割合がNullになっています。(この処理は、いくつかのシナリオに起因して使用される可能性がありますが、もっとも可能性のあるシナリオは、歩合の対象にならない従業員に対してこのプロシージャを実行することです。)

この例外ユニット・テストを作成するステップは、「ユニット・テストの作成」のステップに似ていますが、このテストは表データを変更しないため起動および分解のステップがなく、検証アクションも不要である点が異なります。

「ユニット・テスト」ナビゲータで「テスト」ノードをクリックし、「テストの作成」を選択します。

「ユニット・テスト: ユニット・テストの作成」ウィザードが表示されます。「次へ」をクリックして、各ステップから次へと移動し、ユニット・テストの指定が終了したら「終了」をクリックします。
「操作の選択」で、AWARD_BONUSプロシージャの作成に使用したスキーマのデータベース接続を選択し、「プロシージャ」ノードを開いて「AWARD_BONUS」を選択します。
「テスト名の指定」で、「テスト名」にAWARD_BONUS_NO_COMM_EXCを指定し、「単一のダミー表現を使用して作成します」を選択します。
「起動の指定」で、「次へ」をクリックして次のページに進みます。
「パラメータの指定」で、Input列の値を次のように変更します。

EMP_ID: 1004

SALES_AMT: 5000

「予期した結果」で、値を「例外」に変更し、予期されるエラー番号は「ANY」のままにします。
「検証の指定」で、「次へ」をクリックして次のページに進みます。
「分解の指定」で、「次へ」をクリックして次のページに進みます。
「サマリー」で、情報を確認します。変更が必要な場合は、「戻る」をクリックして必要な画面に戻って変更してから、この「サマリー」ページまで進みます。ユニット・テストの定義を終了できるようになったら、「終了」をクリックします。

このユニット・テストを実行するには、「ユニット・テストの実行」のステップを実行しますが、AWARD_BONUSではなくAWARD_BONUS_NO_COMM_EXCを指定する点が異なります。

「結果」タブで、AWARD_BONUS_NO_COMM_EXCテストが正常に実行されたことを確認し、EMPLOYEES表のデータを参照すると、従業員1004(および、他のすべての従業員)の情報が変更されていないことがわかります。

注意:

例外処理のユニット・テストを別に作成するのではなく、AWARD_BONUSテストに実装を追加(「AWARD_BONUS」を右クリックして「実装の追加」を選択)することもできます。これによってAWARD_BONUSユニット・テストは、従業員1001を使用する「Default」実装と、従業員1004を使用するAWARD_BONUS_NO_COMM_EXC実装の、2つの実装を持つことになります。

このチュートリアルのアプローチでは、2つのユニット・テストを使用した簡単なユニット・スイート・テストを作成できます。ただし、より現実的なユニット・テストのシナリオでは、各プロシージャにユニット・テストを使用し、プロシージャの各テスト・ユニットに実装を追加して、(個々のプロシージャに対応する)複数のユニット・テストをまとめて、1つ以上のテスト・スイートに含めた方が適していることがあります。

関連項目

4.13.7 ユニット・テスト・スイートの作成

AWARD_BONUSプロシージャの2つのテスト・ユニットをまとめたユニット・テスト・スイートを作成します。左側に「ユニット・テスト」ナビゲータが表示されていない場合は、「表示」をクリックして「ユニット・テスト」をクリックします。

「ユニット・テスト」ナビゲータで、「スイート」ノードを右クリックし、「スイートの追加」を選択します。
「ユニット・テスト: テスト・スイートの追加」ダイアログ・ボックスで、スイートの名前にAWARD_BONUS_SUITEを指定します。
「ユニット・テスト」ナビゲータの「スイート」の下で「AWARD_BONUS_SUITE」ノードをクリックします。

AWARD_BONUS_SUITEテスト・スイートのペインが表示されます。
「起動プロセス」および「分解プロセス」は、このテスト・スイートには不要なので指定しないでください。
「追加」(+)アイコンをクリックして、スイートに最初のテストを追加します。
「ユニット・テスト: スイートへのテストまたはスイートの追加」ダイアログ・ボックスで、「AWARD_BONUS」をクリック(選択)し、「実行テストの起動」および「実行テストの分解」を選択してこのユニット・テストの起動アクションおよび分解アクションが実行されるようにし、OKをクリックします。
「追加」(+)アイコンをクリックして、スイートに次のテストを追加します。
「ユニット・テスト: スイートへのテストまたはスイートの追加」ダイアログ・ボックスで、「AWARD_BONUS_NO_COMM_EXC」をクリック(選択)し、OKをクリックします。(AWARD_BONUS_NO_COMM_EXCテストは起動アクションおよび分解オプションを実行しないため、ここでは「実行テストの起動」および「実行テストの分解」オプションは関係ありません。)
「コード・エディタ」ツールバーの「変更のコミット」アイコンをクリックします(またはF11を押します)。

関連項目

4.13.8 ユニット・テスト・スイートの実行

ユニット・テスト・スイートを実行するには、「ユニット・テスト」ナビゲータを使用します。AWARD_BONUS_SUITEテスト・スイートの編集ペインが開いている場合は、「コード・エディタ」ツールバーの「スイートの実行」(緑色の矢印)アイコンをクリックしてスイートを実行します。そうでない場合は、次のステップを実行します。

「ユニット・テスト」ナビゲータで「スイート」ノードを開いて「AWARD_BONUS_SUITE」スイートをクリックします。

「詳細」および「結果」のタブがあるAWARD_BONUS_SUITEテストのペインが表示されます。
「詳細」タブの右上近くで、AWARD_BONUSプロシージャの作成に使用したスキーマのデータベース接続を選択します。

これ以外の値は変更しないでください。(ただし、後で別の指定を使用してユニット・テスト・スイートを実行する必要が生じた場合は、ペイン上部の「コード・エディタ」ツールバーの「編集」(鉛筆)アイコンをクリックして変更できます。)
「コード・エディタ」ツールバーの「スイートの実行」(緑色の矢印)アイコンをクリックします(またはF9を押します)。

スイートの実行後、「結果」タブにフォーカスが移り、AWARD_BONUS_SUITEが正常に実行されたことをすぐ確認できます。

関連項目