| Oracle® SQL Developerユーザーズ・ガイド リリース3.2 B71356-02 |
|
 前 |
 次 |
SQL Developerのユニット・テスト機能では、PL/SQLオブジェクト(ファンクションやプロシージャなど)をテストしたり、これらのオブジェクトの結果について時間の経過を追って監視するためのフレームワークが提供されています。テストを作成した後、各テストに対し、テスト対象と予測結果についての情報を指定します。SQL Developerでのテスト・ユニットの実装は、ユニット・テスト・フレームワークの従来からある既知のxUnitコレクション上にモデル化されます。
ユニット・テスト機能は、設計(Data Modelerによって提供)から開発、テストまでの、データベース・システム開発ライフ・サイクルの主要パートの中で、SQL Developer製品ファミリー内でサポートされるパートです。
この章の内容は次のとおりです。
3.2項「ユニット・テストに使用するSQL Developerユーザー・インタフェース」
3.10項「ユニット・テストのオブジェクトのエクスポートおよびインポート」
3.11項「ユニット・テストのコマンドライン・インタフェース」
SQL Developerのユニット・テスト・フレームワークには、テスト・ケースごとに一連の手順があります。手順を実行する前のユーザー入力と、テスト実行の開始中に必要になるフレームワーク・アクティビティを含めて、次に手順を示します。
テストするオブジェクトを特定します。
ユーザー入力: 特定のPL/SQLプロシージャ、ファンクションなどのオブジェクトを識別します。
フレームワーク・アクティビティ: 処理するオブジェクトを選択します。
起動処理を実行します。
ユーザー入力: PL/SQLブロックを入力するか、起動処理がない場合はNULLを入力します。
フレームワーク・アクティビティ: ブロックを実行します。
ユニット・テストのオブジェクトを実行します。
ユーザー入力: (なし。)
フレームワーク・アクティビティ: ユニット・テストを実行します。
結果をチェックして記録します。
ユーザー入力: 予期したとおりに戻された値(結果)に加えて、検証ルールを識別します。
フレームワーク・アクティビティ: 結果を、検証も含めてチェックし、その結果を保存します。
終了処理(分解)を実行します。
ユーザー入力: PL/SQLブロックを入力するか、分解アクティビティがない場合はNULLを入力します。
フレームワーク・アクティビティ: ブロックを実行します。
テストごとに、前述の手順で求めた情報を入力して、テスト・ケースを作成します。ユニット・テストとは、特定のPL/SQLオブジェクト上の(1つまたは複数の)テスト・ケースのグループです。
各テスト・ケースが1つの実装になります。各ユニット・テストには1つ以上の実装(デフォルトの名前はDefault)があり、1つ以上の他の実装を追加することもできます。たとえば、様々なパラメータ値の組み合わせをテストする実装を、例外を生成する実装も含めて持つことができます。
ユニット・テストを実行すると、各実装が順に実行されます。各実装が、テストの起動アクション(存在する場合)、テスト実装自体、分解アクション(存在する場合)の順に実行します。実装間の相違点は、コール側の引数の値にあります。動的値問合せ(3.5項「動的値問合せを使用したユニット・テストの作成」を参照)は、起動アクション前など、実装全体の実行前に評価されます。
複数のユニット・テストをテスト・スイートにまとめて、グループ化されたアイテムとして実行できるようにすると、指定したテスト・ケースおよびユニット・テストに加えて、そのテスト・スイート独自の起動処理と終了処理を設定できます。
SQL Developerを使用したユニット・テストの詳細を学習するには、必要に応じて次のいずれかのアプローチをとることができます。
3.12項「ユニット・テストの例(チュートリアル)」を参照して手順を実行してから、「SQL Developer: ユニット・テスト」に記載された概念説明に戻ってこれを読みます。
「SQL Developer: ユニット・テスト」に記載された概念説明を読んでから、最後に3.12項「ユニット・テストの例(チュートリアル)」を参照します。
ユニット・テストのためのSQL Developerユーザー・インタフェースには、「ユニット・テスト」ナビゲータ、「ユニット・テスト」サブメニュー、およびその他の機能があります。
図3-1「「ユニット・テスト」ナビゲータ」では、「ユニット・テスト」ナビゲータに、最上位のノードとして「ライブラリ」、「参照」、「レポート」、「スイート」および「テスト」が表示されています。(このナビゲータが表示されていない場合は、「表示」、「ユニット・テスト」の順にクリックします。)
前の図では、最上位のリポジトリ・ノードに、使用される接続の名前(unit_test_repos)と、その接続に関連付けられているユーザーがそのリポジトリに対して「ユーザー」アクセスのみを持つか、「管理者」および「ユーザー」アクセスの両方を持つかが示されています(ここでは両方を持ちます)。(「管理者」および「ユーザー」アクセスについては、3.3項を参照してください。)
前述の図では、ライブラリ・ノードの下にアクションのタイプ(起動、分解、検証)、テスト・スイート1つ、および複数のテストが表示されています。
「ユニット・テスト」サブメニューを表示するには、「ツール」、「ユニット・テスト」の順にクリックします。(「ユニット・テスト」サブメニューのコマンドは、ユニット・テスト・リポジトリに適用されます。)
現在のリポジトリの選択: ユニット・テスト・リポジトリに使用するデータベース接続を選択し、関連するスキーマにリポジトリが存在しない場合は、この接続を使用するリポジトリを作成できます。
現行のリポジトリの選択解除: 現行のユニット・テスト・リポジトリの接続を解除します。ユニット・テスト・リポジトリ(同じリポジトリまたは別のリポジトリ)に再接続するには、「現在のリポジトリの選択」を使用します。
リポジトリの作成/更新: ユニット・テスト・リポジトリを作成して、SQL Developerのユニット・テスト機能に関連するスキーマ・オブジェクトを保持できます。
リポジトリの削除: 現行のユニット・テスト・リポジトリを削除します。
リポジトリのパージ: 現行のユニット・テスト・リポジトリの内容を削除しますが、リポジトリのメタデータは削除しません。
ユーザーの管理: ユニット・テスト・リポジトリに使用するデータベース接続を選択、追加、および変更できます。
共有リポジトリとして選択: 現行のリポジトリを共有リポジトリにします。
共有リポジトリとして選択解除: 現行のリポジトリを共有されないリポジトリにします。
「表示」メニューには、ユニット・テストに関連する次の項目があります。
ユニット・テスト: 「ユニット・テスト」ナビゲータの表示を切り替えます。
SQL Developerユーザー・プリファレンスのウィンドウ(「ツール」をクリックし、「プリファレンス」をクリックして表示)には、「ユニット・テストのパラメータ」ペインがあります。
特定のプリファレンスの詳細は、このペインで「ヘルプ」をクリックして1.18.14項を参照してください。
ユニット・テスト・リポジトリは、SQL Developerがユニット・テスト機能の使用を管理するために保持する、表、ビュー、索引、およびその他のスキーマオブジェクトの一連のセットです。(これらのオブジェクトのほとんどは、名前にUT_が付きます。)リポジトリに個別のデータベース・ユーザーを作成することも、既存のデータベース・ユーザーのスキーマを使用することもできますが、メインの共有リポジトリを1つ持つ環境の簡便さを考えると、個別のデータベース・ユーザーを作成することの方が多いと考えられます(3.12項「ユニット・テストの例(チュートリアル)」では、実際にこの操作を行います)。
リポジトリは、様々なユニット・テスト操作の実行を許可するデータベース・ユーザーの数に応じて、共有または非共有に設定できます。
非共有リポジトリでは、そのユニット・テスト・リポジトリのスキーマ・オブジェクトを所有するデータベース・ユーザーのみを、リポジトリを変更する操作に使用できます。
たとえば、複数の非共有リポジトリを作成すると、個々の開発者はプライベートなリポジトリを作成できます。
共有リポジトリでは、リポジトリ・オブジェクトの所有者と、そのリポジトリへの管理者としてのアクセス権限(具体的には、UT_REPO_ADMINISTRATORロール)を付与された他のユーザーが、ユーザーの管理などの管理操作を実行できます。
共有リポジトリは最大で1つ作成でき、チーム開発の環境ではこれを使用することが一般的です。リポジトリ管理者は、ユーザーを追加し(3.3.1項を参照)、リポジトリのステータスの共有と非共有を切り替えることができます。(リポジトリを共有にすると、SQL Developerは、該当するリポジトリ・オブジェクトにパブリック・シノニムを作成します。)
非共有リポジトリを共有に変更するには、「ツール」、「ユニット・テスト」、「リポジトリ」、「共有リポジトリとして選択」の順にクリックします。共有リポジトリを非共有に変更するには、「ツール」、「ユニット・テスト」、「リポジトリ」、「共有リポジトリとして選択解除」の順にクリックします。
ユニット・テストおよびユニット・スイートを作成して実行するには、リポジトリにユーザーとしてアクセスする権限(具体的には、UT_REPO_USERロール)が付与されたデータベース・ユーザーの接続を使用する必要があります。ユーザーの管理などのリポジトリの管理操作を実行するには、リポジトリに管理者としてアクセスする権限(具体的には、UT_REPO_ADMINISTRATORロール)が付与されたデータベース・ユーザーの接続を使用する必要があります。
たとえば、ユーザーSCOTT、JONES、SMITHがユニット・テスト機能を使用できるように、共有リポジトリにユーザー権限でアクセスできるようにし、SYSとリポジトリ・オブジェクト(「ユニット・テストの例(チュートリアル)」のUNIT_TEST_REPOSなど)の所有者のみが、この共有リポジトリに管理者権限でアクセスするとします。
データベース・ユーザーにいずれかのタイプのアクセス権を付与するには、「ツール」、「ユニット・テスト」、「リポジトリ」、「ユーザーの管理」の順にクリックします。リポジトリ・オブジェクトの所有者のデータベース接続、または管理者権限でのアクセス権を付与されたその他のユーザーを選択します。「ユニット・テスト: ユーザーの管理」ダイアログ・ボックスが表示されます。
ユニット・テストを編集するには、「ユニット・テスト」ナビゲータでユニット・テスト名をクリックし、そのユニット・テストを実行するために必要な接続を選択します。ユニット・テストの仕様の詳細を示す「詳細」と、テストを実行またはデバッグした場合の結果を示す「結果」の、2つのタブのあるペインが表示されます。
「詳細」タブの下にあるツールバーには、次の図に示すアイコンを含むツールバーがあります。
「ビューの固定」(ピン)では、「ユニット・テスト」ナビゲータで別のユニット・テストをクリックしたときに、SQL Developerウィンドウ内のペインが保持され、別のユニット・テストには別のタブと詳細表示ペインが作成されます。ピンをもう一度クリックすると、ユニット・テストの詳細表示ペインを再利用できます。
「リフレッシュ」では、ペイン内の表示が更新されます。
「デバッグ」は、デバッグ・モードでユニット・テストの最初または次の実装を実行開始し、その結果を「結果」タブに表示します。
「実行」は、ユニット・テストの通常実行を開始して、「結果」タブに結果を表示します。(「実行」をクリックする前に、右側のデータベース接続を選択して、この実行操作を行うデータベース・ユーザーを指定できます。)
「編集」(鉛筆のアイコン)では、ユニット・テストの仕様を編集できます。(ユニット・テストを変更できない場合は、「「編集」アイコンをクリック。)
「変更のコミット」では、ユニット・テストに対する変更を保存します。
「変更のロールバック」は、ユニット・テストに対する変更を保存せず破棄します。
「編集」アイコンをクリックすると、起動処理、分解処理、および各実装の詳細を変更できます。
また、「コード・カバレッジ統計の収集」を指定すると、SQL Developerはコード・カバレッジに関連する統計が収集されます。ユニット・テスト実行から収集された統計を参照するには、「テスト実行のコード・カバレッジ」レポートを使用します。このレポートの「コード・カバレッジの詳細」ペインで、サマリー情報の行をクリックします。
ユニット・テストを作成するときに、入力データを正確に指定するのではなく、テストの入力として表のデータを使用する動的値問合せを作成することができます。問合せによって1つ以上の行の指定した列から値が戻され、戻されたすべての値セットは、そのテストに指定した任意のプロセス検証によってチェックされます。動的値問合せの一般的な利用方法の1つに、テストの結果である給与または価格が指定した範囲内にあるかどうかをチェックするなどの「適正」テストがあります。
動的値問合せを使用するテストを作成するには、その問合せが使用する表を作成して値を入力し、テスト対象のオブジェクトと任意の起動および分解アクションを指定してテストを作成し、検証アクション(問合せが行を戻すかどうかなど)を指定します。
|
注意: テスト内のすべての実装を実行する前に(テストの起動アクションを含めて)、動的値問合せを実行します。動的値問合せを評価する前に表に値を入力する必要がある場合は、そのテストを含むスイーツの起動アクションを実行できます。 |
次の例は、3.12項「ユニット・テストの例(チュートリアル)」で、少なくとも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ユニット・テストを実行します。(ユニット・テストの基本的な実行手順は、3.12.5項を参照してください。)
参照とは、1つ以上のデータ型の、テスト可能なデータ値を含むオブジェクトです。参照は、主に次の目的で使用されます。
参照を作成するには、次の手順を実行します。
「ユニット・テスト」ナビゲータで、「参照」ノードを右クリックし、「カテゴリの追加」を選択します。
カテゴリ名(EMP_ID_LOOKUPなど)を指定します。
参照値(テストが可能な有効および無効なデータ値)を指定するデータ型ごとに、カテゴリ名を右クリックし、「データ型の追加」を選択してデータ型を選択し、+(プラス記号)アイコンを使用して必要な数のデータ値を追加します。
(null)は、作成する各参照の各データ型の値のリストに自動的に含まれることに注意してください。
たとえば、3.12項「ユニット・テストの例(チュートリアル)」で説明する環境では、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
「ユニット・テスト」ナビゲータのコンテキスト(右クリック)メニューを使用すると、参照カテゴリの削除や名前の変更ができます。参照カテゴリに設定したデータ型も削除できますが、この場合の「削除」とは、その参照カテゴリのデータ型に現在指定されているデータ値を削除することで、これによって「ユニット・テスト: データ型の追加」ダイアログ・ボックスで選択したデータ型を使用できるようになります。
ユニット・テスト実装に入力パラメータを指定するときに、「カテゴリの参照」コントロールをクリックして参照カテゴリを選択できます。その後、「入力」の下のセルをクリックして、下向き矢印をクリックすると指定した参照から値を選択できます。(リストから選択するのではなく、値を入力することもできます。)
たとえば、3.6項の説明に従ってEMP_ID_LOOKUP参照カテゴリを作成して、パラメータを指定するときこれを参照カテゴリとして選択し、EMP_IDパラメータの「入力」セルのドロップダウンリストの値として-100、99、1001、1002、1003、1004、2000、9999、および(null)を表示させることができます。(SALES_AMTパラメータでは、SALES_AMT_LOOKUPカテゴリを使用します。)
あるデータ型の特定の値をテストするための実装が必要な場合、手動で作成するのではなく、参照カテゴリを使用して実装を自動生成できます。これを行うには、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の形式の名前が付いたもの)が自動作成されます。何らかの検証アクションを実行するには、生成された各実装を編集して指定する必要があります。
検証アクションで変数置換を使用すると、プロシージャまたはファンクションの入力および出力パラメータの値、またはファンクションの戻り値に基づいた結果を提供する、動的な検証を記述できます。検証アクションでは、次の形式で文字列を指定できます。
入力パラメータの場合: {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ブロックで置換が実行されます。
ユニット・テストのライブラリを使用すると、アクションを保存して、複数のユニット・テストの定義で再利用できます。このようなユーザー定義のアクションは、「ユニット・テスト」ナビゲータの「ライブラリ」ノードの下に表示されます(3.2項を参照)。次のカテゴリのライブラリに、次の種類のアクションを保存できます。
動的値問合せ
起動アクション
分解アクション
検証アクション
ほとんどのカテゴリにはサブカテゴリがあります。たとえば、「起動」アクション・ノードには、サブノード「表または行のコピー」および「ユーザーPL/SQLコード」があります。ライブラリにエントリを追加する手順は、次のとおりです。
「ライブラリ」階層を開いて、関連する最下位レベルのノード(「起動」の下の「ユーザーPL/SQLコード」など)を表示し、右クリックして「[アクション・タイプ]の追加」を選択し、アクションの名前を指定して、新規作成したアクションの名前をクリックして指定を完了します。
ユニット・テストを作成するときにアクションを指定するには、「ライブラリに公開」オプションを使用して、アクションの名前を入力し「パブリッシュ」をクリックします。(このアクションは、「ユニット・テスト」ナビゲータに表示される「ライブラリ」の、適切なカテゴリおよびサブカテゴリの下に追加されます。)
ユニット・テストを作成したときにライブラリのアクションを使用するには、「ユニット・テスト: ユニット・テストの作成」ウィザードの適切なページで、またはユニット・テストの編集時に「ライブラリ」の下のリストから選択します。ライブラリからアクションを選択する際、アクションをプロセス(起動、分解または検証)に組み込むために、次のオプションを指定できます。
コピー: アクションのコピーを使用して、コピーを編集できます(ユーザーPL/SQLコード・プロシージャのWHERE句を編集する場合など)。後でライブラリでそのアクションを変更しても、変更後のアクションが自動的にプロセスに再コピーされることはありません。
サブスクライブ: ライブラリに格納されているアクションが使用されます。(「サブスクライブ」オプションを使用した場合、プロセス内でこのアクションを編集することはできません。)後でライブラリでそのアクションを変更した場合、その変更後バージョンが自動的にプロセスで使用されます。
複数のSQL Developerレポートによって、ユニット・テストに関連する操作の情報が提供されます。これらのレポートは、「ユニット・テスト」ナビゲータの「レポート」ノードの下にリストされます。使用できるレポートには、次のものがあります。
すべてのスイート実行
テスト実装のすべての実行
すべてのテスト実行
スイート実行のコード・カバレッジ
スイート・テスト実装の実行
スイート・テスト実行
テスト実装の実行
テスト実行のコード・カバレッジ
ユーザー・テスト実行(ユーザーがグループ化したテスト実行)
ユニット・テストの各レポートの上部ペインには、各項目のサマリー情報行が含まれています。いずれかの項目の詳細情報を参照するには、その行をクリックすると、サマリー情報の下にある1つ以上の詳細ペインに情報が表示されます。たとえば、「すべてのテスト実行」レポートのサマリー行をクリックすると、「テスト実行の詳細」および「最新のコード・カバレッジ」タブの下に、そのテスト実行の詳細が表示されます。
一部のレポートでは、バインド変数のプロンプトが表示されるので、デフォルト値を受け入れて関連するすべての項目を表示するか、またはバインド変数を入力して表示される項目を制限できます。(詳細は、「レポートのバインド変数」を参照してください。)
ライブラリ(起動アクション、検証アクション、分解アクションなど)に保存したユニット・テスト、スイート、およびオブジェクトをエクスポートおよびインポートできます。
オブジェクトをエクスポートすると、すべての依存オブジェクトが結果のXMLファイルに含まれます。たとえば、スイートをエクスポートすると、スイートに含まれるすべてのテストと、スイートの各テスト内の起動、検証、分解の各アクションが結果のXMLファイルに含まれます。
オブジェクトをエクスポートするには、「ユニット・テスト」ナビゲータでオブジェクトの名前を右クリックし、「ファイルにエクスポート」を選択して、オブジェクトの定義を含めるXMLファイルの場所と名前を指定します。
ユニット・テストのオブジェクトをXMLファイルからインポートすると、「ユニット・テスト」ナビゲータ階層の適切な場所に、ファイル内のすべてのオブジェクトが作成されます。XMLファイル内のオブジェクトと同じ名前で同じタイプのオブジェクトがリポジトリ内に既に存在する場合は、XMLファイル内のオブジェクトで置換(上書き)されます。
ユニット・テストのオブジェクトをインポートするには、「ツール」、「ユニット・テスト」、「ファイルからインポート」の順にクリックして、インポート操作に使用するXMLファイルを指定します。
ユニット・テストおよびスイートの実行と、ユニット・テストのオブジェクトのエクスポートおよびインポートは、SQL Developerのグラフィカル・インタフェースで実行するだけでなく、オペレーティング・システムのコマンドラインでututilバッチ・ファイル(Windows)またはシェル・スクリプト(Linux)を使用することもできます。ututilは、SQL Developerのインストール先の下のsqldeveloper\sqldeveloper\binフォルダまたはsqldeveloper/sqldeveloper/binディレクトリにあります。
ututil.batまたはututil.shでは、テストまたはスイートを実行するrunコマンド、エクスポート操作を実行するexpコマンド、インポート操作を実行するimpコマンドを使用できます。構文およびオプションの詳細を参照するには、システムのコマンド・プロンプトで、パラメータを指定せずにututilを実行します。次に例を示します。
C:\Program Files\sqldeveloper\sqldeveloper\bin>ututil ututil -run ? ututil -exp ? ututil -imp ?
使用するコマンドの詳細を表示するためのコマンドを入力します。たとえば、ututil -run ?と入力します。
ututil -runコマンドには次のパラメータがあります。
-db <connection name>には、ユニット・テストの実行に使用するデータベース・ユーザーに関連付けられているデータベース接続を指定します。
-repo <connection name>には、ユニット・テストの実行に使用するユニット・テスト・リポジトリに関連付けられているデータベース接続を指定します。
{-log <0,1,2,3>}には、次に示すロギング・レベルを指定します。
0 = ロギングなし(デフォルト)。
1 = ステータスのレポート。
2 = ステータスおよびエラー・メッセージのレポート。
3 = ステータス、エラー・メッセージおよび戻りID値のレポート。
{-return <return id>}には、戻りID値を指定します(結果表の主キーとして使用され、自動ツールがデータベースからの結果を問い合せることができるようになります)。
次の例では、Program Filesの下にSQL DeveloperをインストールしたWindows環境で、AWARD_BONUSという名前のユニット・テストを実行しています。(コマンドライン・インタフェースでは、テストおよびスイートの名前で大文字と小文字が区別されることに注意してください。)この例では、ユーザーunit_test_reposのリポジトリ接続を使用し、ユーザーfredでテストを実行しています。
> cd c:\Program Files\sqldeveloper\sqldeveloper\bin > ututil -run -test -name AWARD_BONUS -repo unit_test_repos -db fred
次の例では、AWARD_BONUSという名前のユニット・テストをエクスポートしています。ユーザーunit_test_reposのリポジトリ接続を使用し、エクスポートした定義をファイルC:\ut_xml\award_bonus_test.xmlに保存しています。
> ututil -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のリポジトリ接続を使用しています。
> ututil -imp -repo unit_test_repos -file c:\ut_xml\award_bonus_suite.xml
コマンドラインから実行したテストまたはスイートの結果をチェックするには、SQL Developerを起動して「すべてのテスト実行」および「すべてのスイート実行」レポートを参照します(3.9項「ユニット・テストのレポート」を参照)。
この項では、表およびPL/SQLプロシージャの作成、有効および無効な入力データのテスト・ケースを使用したユニット・テストの作成、ユニット・テストの実行、ユニット・テスト・スイートの作成および実行を行う簡単な例を示します。この例では、給与情報を含む従業員データの表があり、給与が基本給と歩合ベースのボーナスで構成される販売員のボーナスを計算するプロシージャを作成する必要があると仮定します。
|
注意: Oracle By Example(OBE)チュートリアル「Performing a Unit Test of Your PL/SQL in Oracle SQL Developer 2.1」は、このチュートリアルに似ていますが、ここではOracleサンプルHRスキーマから、列と行の数がより多くデータも異なるEMPLOYEES表をコピーして使用します。SQL Developer OBEの詳細は、開始ページを参照してください(「ヘルプ」、「開始ページ」の順にクリック)。 |
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部門以外の従業員の給与に歩合ベースのボーナスを追加しようとして発生します。
この例の以降の説明では、主要な手順を示します。
このチュートリアルでは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;
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プロシージャを作成します。
作成してSQL Developerで維持するスキーマ・オブジェクトを保持するために、データベースにユニット・テスト・リポジトリが必要になります。このリポジトリ用に別のデータベース・ユーザーを作成することも、既存のデータベース・ユーザーのスキーマを使用することもできますが、学習手順と、後で必要になる可能性のあるデバッグ手順を簡単にするために、ユニット・テスト・リポジトリ用に別のスキーマを作成することをお薦めし、この項の手順でもこのアプローチを反映します。
ユニット・テスト・リポジトリのデータベース・ユーザー(UNIT_TEST_REPOSなど)を作成します。DBA権限のあるデータベース接続を使用して、「接続」ナビゲータの「他のユーザー」をクリックし、「ユーザーの作成」を選択します。ユーザー名にUNIT_TEST_REPOSを指定し、他の必要な情報をすべて入力します。
「デフォルト表領域」にUSERSを指定し、「一時表領域」にTEMPを指定します。
「システム権限」でCREATE SESSIONを有効にし、「適用」、「閉じる」の順にクリックします。
作成したユニット・テスト・リポジトリ・ユーザーに対するデータベース接続を作成します。「ツール」、「ユニット・テスト」、「ユーザーの管理」の順にクリックします。「接続の選択」ダイアログ・ボックスで、プラス記号(+)アイコンをクリックして、ユニット・テスト・リポジトリ・ユーザーに対する新規データベース接続を作成します(unit_test_reposなど)。
「保存」をクリックして接続を保存し、「取消」をクリックしてダイアログ・ボックスを閉じます。
作成したユーザーのスキーマにリポジトリを作成します。「ツール」、「ユニット・テスト」、「現在のリポジトリの選択」の順にクリックします。ユニット・テスト・リポジトリ・ユーザーに対するデータベース接続(unit_test_reposなど)を指定します。その接続にリポジトリが存在しないことを示すメッセージが表示された場合は、プロンプトに従って新規リポジトリを作成します。
SQL Developerによっていくつかのプロンプトが表示され、ユニット・テスト・リポジトリ・ユーザーに必要な権限を付与するコマンドを実行できます。それぞれに「はい」をクリックし、パスワードのプロンプトにSYSアカウントのパスワードを入力します。
最初のユニット・テストを作成するには、「ユニット・テスト」ナビゲータを使用します。左側にこのナビゲータが表示されていない場合は、「表示」をクリックして「ユニット・テスト」をクリックします。「ユニット・テスト」ナビゲータについては3.2項を参照してください。
「ユニット・テスト」ナビゲータで「テスト」ノードをクリックし、「テストの作成」を選択します。
「ユニット・テスト: ユニット・テストの作成」ウィザードが表示されます。それ以降のステップで「次へ」をクリックして、各ステップから次へと移動し、ユニット・テストの指定が終了したら「終了」をクリックします。
「操作の選択」で、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行の結果を戻すため、検証アクションの結果は成功です。
この手順では、次のように、変数置換(3.7項を参照)を使用したSELECT文を指定することもできます。
SELECT * FROM employees
WHERE employee_id = {EMP_ID} AND salary = 9400
ただし、この例のシナリオでは、変数置換を使用しても大きなメリットはありません。
「分解の指定」で、ユニット・テストによってデータが変更される前にEMPLOYEES表の元のデータ値をリストアする必要があるため、「表または行のリストア」を選択します。プロンプトが表示されたら、「ターゲット表」および「ソース表」に表示される値(それぞれ、EMPLOYEESおよび一時表の名前)を受け入れます。
「サマリー」で、情報を確認します。変更が必要な場合は、「戻る」をクリックして必要な画面に戻って変更してから、この「サマリー」ページまで進みます。ユニット・テストの定義を終了できるようになったら、「終了」をクリックします。
ユニット・テストを実行するには、「ユニット・テスト」ナビゲータを使用します。左側にこのナビゲータが表示されていない場合は、「表示」をクリックして「ユニット・テスト」をクリックします。「ユニット・テスト」ナビゲータについては3.2項を参照してください。
「ユニット・テスト」ナビゲータで「テスト」ノードを開いて「AWARD_BONUS」テストをクリックします。
「詳細」および「結果」のタブがあるAWARD_BONUSテストのペインが表示されます。
「詳細」タブの右上近くで、AWARD_BONUSプロシージャの作成に使用したスキーマのデータベース接続を選択します。
これ以外の値は変更しないでください。(ただし、後で別の指定またはデータ値を使用してユニット・テストを実行する必要が生じた場合は、ペイン上部の「コード・エディタ」ツールバーの「編集」(鉛筆)アイコンをクリックして変更できます。)
「コード・エディタ」ツールバーの「テストの実行」(緑色の矢印)アイコンをクリックします(またはF9を押します)。
ここで「結果」タブにフォーカスが移り、AWARD_BONUSが正常に実行されたことをすぐ確認できます。
EMPLOYEES表のデータをチェックすると、従業員1001の給与は以前と同じ(8400)ですが、これは、このユニット・テストの起動アクションが元のデータを一時表にコピーし、分解アクションがEMPLOYEES表に元のデータをリストアしたためです。
別のユニット・テストを作成して、COMMISSSION_PCT値がNullで、歩合(ボーナス)の計算ができない従業員のための例外処理を作成します。このチュートリアルでは、テスト・データの従業員1004の歩合の割合がNullになっています。(この処理は、いくつかのシナリオに起因して使用される可能性がありますが、もっとも可能性のあるシナリオは、歩合の対象にならない従業員に対してこのプロシージャを実行することです。)
この例外ユニット・テストを作成する手順は、3.12.4項の手順に似ていますが、このテストは表データを変更しないため起動および分解のステップがなく、検証アクションも不要である点が異なります。
「ユニット・テスト」ナビゲータで「テスト」ノードをクリックし、「テストの作成」を選択します。
「ユニット・テスト: ユニット・テストの作成」ウィザードが表示されます。「次へ」をクリックして、各ステップから次へと移動し、ユニット・テストの指定が終了したら「終了」をクリックします。
「操作の選択」で、AWARD_BONUSプロシージャの作成に使用したスキーマのデータベース接続を選択し、「プロシージャ」ノードを開いて「AWARD_BONUS」を選択します。
「テスト名の指定」で、「テスト名」にAWARD_BONUS_NO_COMM_EXCを指定し、「単一のダミー表現を使用して作成します」を選択します。
「起動の指定」で、「次へ」をクリックして次のページに進みます。
「パラメータの指定」で、Input列の値を次のように変更します。
EMP_ID: 1004
SALES_AMT: 5000
「予期した結果」で、値を「例外」に変更し、予期されるエラー番号は「ANY」のままにします。
「検証の指定」で、「次へ」をクリックして次のページに進みます。
「分解の指定」で、「次へ」をクリックして次のページに進みます。
「サマリー」で、情報を確認します。変更が必要な場合は、「戻る」をクリックして必要な画面に戻って変更してから、この「サマリー」ページまで進みます。ユニット・テストの定義を終了できるようになったら、「終了」をクリックします。
このユニット・テストを実行するには、3.12.5項の手順を実行しますが、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つのユニットテストを使用した簡単なユニット・スイート・テストを作成できます(3.12.7項を参照)。ただし、より現実的なユニット・テストのシナリオでは、各プロシージャにユニット・テストを使用し、プロシージャの各テスト・ユニットに実装を追加して、(個々のプロシージャに対応する)複数のユニット・テストをまとめて、1つ以上のテスト・スイートに含めた方が適していることがあります。 |
AWARD_BONUSプロシージャの2つのテスト・ユニットをまとめたユニット・テスト・スイートを作成します。左側に「ユニット・テスト」ナビゲータが表示されていない場合は、「表示」をクリックして「ユニット・テスト」をクリックします。「ユニット・テスト」ナビゲータについては3.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を押します)。
ユニット・テスト・スイートを実行するには、「ユニット・テスト」ナビゲータを使用します。AWARD_BONUS_SUITEテスト・スイートの編集ペインが開いている場合は、「コード・エディタ」ツールバーの「スイートの実行」(緑色の矢印)アイコンをクリックしてスイートを実行します。そうでない場合は、次の手順を実行します。
「ユニット・テスト」ナビゲータで「スイート」ノードを開いて「AWARD_BONUS_SUITE」スイートをクリックします。
「詳細」および「結果」のタブがあるAWARD_BONUS_SUITEテストのペインが表示されます。
「詳細」タブの右上近くで、AWARD_BONUSプロシージャの作成に使用したスキーマのデータベース接続を選択します。
これ以外の値は変更しないでください。(ただし、後で別の指定を使用してユニット・テスト・スイートを実行する必要が生じた場合は、ペイン上部の「コード・エディタ」ツールバーの「編集」(鉛筆)アイコンをクリックして変更できます。)
「コード・エディタ」ツールバーの「スイートの実行」(緑色の矢印)アイコンをクリックします(またはF9を押します)。
スイートの実行後、「結果」タブにフォーカスが移り、AWARD_BONUS_SUITEが正常に実行されたことをすぐ確認できます。
