RDiのコード・カバレッジで、前回のテストでカバーされたコードを知る
1つまたは複数のプログラムに変更を加えたときに、すべての変更箇所をテストしているでしょうか。もちろん、コードの他の部分もすべてテストして、他にどこか壊れたところがないか確かめることも必要です。前回、プログラムに変更を加えた際、そうしたことを実施したでしょうか。あるいはまた、すべてのコードをテストしたでしょうか。RDiのコード・カバレッジ機能では、前回のテストでカバーされたコード部分を知ることができます。
この記事では、コード・カバレッジを使用する目的や基本的な操作方法など、コード・カバレッジの概要について説明します。実行方法について説明する前に、まずはコード・カバレッジ テストの結果と、コード・カバレッジがどのような処理を行ってくれるのかを見てみることとしましょう。興味が高まるかもしれません。下の図1は、1つのプログラムに対して実行したテストのコード・カバレッジ サマリー レポートです。テスト中にプログラムおよびプログラムの各サブプロシージャー内のコード行の何パーセントが実際に実行されたかが示されています。バージョン9.6.0.5で、レポート機能に対していくつかの大きな変更が加えられています。以前のリリースでコード・カバレッジを使用したことがある方にとっては、レポートの体裁が少し変わったように思えるかもしれませんが、表示されている情報は基本的に同じです。
このレポートからは、テストで触れられたのはプログラムのコード全体の73%のみだったことが見て取れます。プログラム内のプロシージャーを見てみると、分析の際に、1つのプロシージャー（FILLPRCODE）がまったくテストされなかったことが分かります。また、メイン プロシージャーと、もうひとつのサブプロシージャーのコード行に、カバーされなかったコード行が数多くあることも見て取れます。どのコード行がカバーされ、どのコード行がカバーされなかったか詳しく調べるには、プログラムの名前をダブルクリックしてコード・カバレッジ ソース ビューを開きます（図2）。
ご覧のように、シーケンス番号の左側に赤色または緑色のインジケーターのマークが付いたソースが表示されます。テスト実行中に厳密にどのコード行が触れられたか（触れられなかったか）が示されます。左側に赤色のマークが付いた2つのコード行に注目してください。これら2つの行は一度も実行されなかったことを示しており、このプログラムの2つの機能がテストされなかったということを意味しています。
コード・カバレッジの実行方法
コード・カバレッジを試してみようという気になった方は、コード・カバレッジ分析テストの実行方法について見てみましょう。こうした基礎知識や手順について説明した短いビデオを用意しています（こちらでご覧いただけます）。
コード・カバレッジはデバッグ エンジンを使用します。そのため、RDiのデバッガーを使い慣れている方なら、プロセスは簡単だと感じるはずです。そうでない方に向けては、いくつかのアドバイスが有用かもしれません。また、RDiのデバッガーと同様に、分析されるプログラムには、ソースまたはリスト ビュー（またはその両方）のデバッグ データが含まれている必要があるということにもなります。
さらにまたRDiのデバッガーと同じく、コード・カバレッジ セッションを開始するには、主に2つの方法があります。サービス エントリー ポイント（SEP）を使用する方法と、手動で構成を作成する方法です。この記事では、コード・カバレッジにSEPを使用する方法を中心に説明します。手動構成を作成および使用する方法については、今後の記事で詳しく説明する予定です。
先に進む前に、RDiワークスペースの「IBM i デバッグ」設定ページを確認しておく必要があります。プログラムのデバッグ時に、常に「実動ファイルを更新する（Update production files） *Yes"」に設定する必要がある場合は、このページでプリファレンスとしてそのように設定します。デフォルトでオンにはなりません。この設定は、コード・カバレッジ セッションとデバッグの両方に適用されます。
SEPを使用してコード・カバレッジを実行する
まずはSEPのプロセスから始めます。以下に、SEPを使用したコード・カバレッジで、プログラムのテストを分析するために行う作業の全体の流れを示します。その後で、ステップごとに詳しく見て行くこととします。
- テストする初期プログラムにサービス エントリー ポイントを設定する。
- SEPがコード・カバレッジ用（デバッグ用ではなく）であることを確認する。
- 必要に応じて、SEP起動構成を修正してプログラムまたはサービス プログラムを追加する。
- テストするプログラムを実行する。
- 初期プログラムが終了すると、「コード・カバレッジ結果」ビューが表示され、エディター ウィンドウにデータが入力されてサマリー レポートが表示されます。プログラムをダブルクリックして、ソース レベル詳細を表示します。
ステップ1: 「リモート・システム」ビューで、分析するプログラム（またはサービス プログラム）を右クリックします。複数のオブジェクトを分析したい場合は、後でオブジェクトを複数追加できますが、ここで選択するプログラムは、テスト中に呼び出されるプログラムのうちの最初のプログラムである必要があります。コンテキスト メニューから、「Debug or Code Coverage (Service Entry)」 > 「Set Service Entry Point」を選択します。RDiにより、表内のプログラムのエントリーで「IBM i サービス・エントリー・ポイント」ビューを開くとSEPが開始されることを知らせるメッセージが表示されます。エントリーにはユーザーIDの項目も含まれていることに注目してください。テスト実行時には、そのユーザーIDで実行する必要があります。必要な場合は、この表でエントリーを修正することによって、ユーザーIDを自分のユーザーIDから変更できます。
ステップ2: デバッグでSEPを使用したことがある場合は、注意しておくべき重要な相違点があります。SEPには、デバッグ モードとコード・カバレッジ モードがありますが、デフォルトでは、最初にデバッグ モードが使用されます。モードの切り替えが必要な場合は、コンテキスト メニューから、またはツール バーのデバッグ アイコンのすぐ右にある「コード・カバレッジ」アイコンをクリックして行うことができます。図3に、両オプションをハイライトして示しています。
ステップ3: 他のプログラムやサービス プログラムを分析に含めたい場合は、それらをセッションに追加する必要があります。それを行うには、RDiによって使用される汎用のSEP構成を修正します。SEPエントリーのコンテキスト メニューから「起動構成を開く」を選択します。上の図3には、そのコンテキスト メニューのオプションが表示されています。
下の図4は、SEP起動構成にプログラムを追加するためのダイアログと、「追加」ボタンを押した後に表示されるポップアップ ウィンドウを示しています。
これで、コード・カバレッジ モードでのSEPのセットアップが完了しました。ホスト システムは、ユーザー プロファイル（SEPで指定）によってプログラム（これもSEPで指定）の実行が開始されるのを監視するようになります（システム上のどこで開始されても監視されます）。デバッガーの場合と同じです。SEPについてさらに詳しくは、RDiデバッガーでのSEPの使用法について記した記事をご覧ください。
ステップ4: 次のステップは、テストを実行することです。SEPを使用しているため、テストは対話型ジョブ、バッチ ジョブ、Webまたはデータベース サーバー ジョブのいずれかで行われますが、どれでも構いません。この例では、シンプルに対話型セッションからプログラムを呼び出します。
ステップ5: プログラムの実行が終了すると、RDiは、今回のテスト実行のエントリーが表示された「コード・カバレッジ結果」ビューを開きます（必要な場合）。下の図5は、今回のテスト実行の「コード・カバレッジ結果」ビューを示しています（以前に実行したいくつかのテスト セッションの結果も併せて表示されている）。また、上の図1で示したようなエディター ウィンドウで、コード・カバレッジ レポートが自動的に開かれます。
SEPの使用には、いくつかの制限事項があります。最も重要なものは、初期プログラムはILE言語プログラムでなければならないことです（つまり、CLPやRPG400であってはなりません）。そのような場合は、CLPまたはRPG400を呼び出すだけの小さなCLLEまたはRPGLEプログラムを作成することができます。あるいは、自動的にプログラムを呼び出す構成を手動で作成することもできます。次回の記事では、コード・カバレッジの手動構成を作成して使用する手順について説明する予定です。
お楽しみはこれから
この記事では、コード・カバレッジの基本的な使い方について説明しました。次回の記事では、手動構成について説明するとともに、複数のコード・カバレッジ実行結果をマージしたレポートを表示する方法や、ここで説明したようなRDiのプロセスを使用するのではなく、ホストでCLコマンドを介してコード・カバレッジを実行する方法など、このツールの使い方について、さらに詳しく取り上げる予定です。
