単体テスト
アプリケーションのルール設定が誤っていると、ケース処理に遅れが生じることがあります。 エラーが発生した場合、エンドユーザーへの仕事の再割り当てや、管理者によるケースの修正が必要になることもあります。 たとえば、Fulfillment部門にルーティングする必要があるケースについて考えてみましょう。 そのケースが代わりにAccounting部門にルーティングされると、経理担当者がFulfillmentにルーティングし直す必要があります。 経理担当者は仕事の再ルーティングに時間を費やし、フルフィルメント部門は待機することになります。 その結果、ケースの再割り当て中に顧客に対して遅れが発生します。
アサインメントの誤ったルーティングなどの設定エラーを防ぐには、デベロッパーがアプリケーションをテストします。 アプリケーションテストの最も基本的な形式は、個々のルールの単体テストです。 単体テストは、最小単位の機能の品質テストを可能にし、継続的なアプリケーションデリバリーをサポートします。 Pegaアプリケーションの場合、最小単位は個々のルールです。
単体テストの目的は、アプリケーションの各要素（たとえば、デシジョンテーブルやレポートディフィニッションなど）が想定通りに機能するかどうかを検証することです。 あるルールの設定エラーがアプリケーション内の別のルールに影響を及ぼすと、ケース処理に大幅な遅れが生じますが、単体テストを行うことでそのようなリスクを軽減できます。
単体テストを使って、設定エラーを削減してください。 個々のルールを単体テストすると、それらのルールを設定するときにそれぞれのルールが想定通りに機能することがわかります。 たとえば、プロパティを評価するデシジョンツリーについて考えてみましょう。 次の図に示すように、アプリケーションでレポートディフィニッションをソースとするデータページからプロパティが読み取られます。 デシジョンツリーが誤った結果を返す場合、データページに正しいデータが含まれていれば、そのエラーをデシジョンツリーに分離できます。
次の問題に答えて、理解度をチェックしましょう。
個々のルールの単体テスト
Dev Studioで「Rule form」ツールバーの「Actions > Run」をクリックすると、指定したテストデータを使ってルールをテストできます。
補足： バイナリファイルルールなど一部のルール タイプに対しては、Pegaは単体テストのオプションを提供していません。 ルールの単体テストを実行できない場合、「Run」オプションは使用できません。
「 Run Rule」ウィンドウの外観はルールのタイプによって異なるため、ルールを実行する方法はルールのタイプによって異なります。 ただし、一般的にルールはテストについて定義したテストページからデータを使って実行します。
ルールを実行すると、ルールレゾリューションが利用されます。 ルールの単体テストを実行するときに新しいバージョンのルールがある場合は、新しいバージョンのルールが実行されます。
自動テスト用の単体テストを記録する
テストの実行後に、そのテストを再利用可能なテストケースに変換することもできます。そうすれば、テストをいつでも実行できるようになります。 テストケースは、ルールが想定通りの結果を返すかどうかを判定するために使う、1つまたは複数のテスト可能な条件を特定します。 再利用可能なテストケースを作成すると、継続的デリバリーモデルに対応でき、新しいルールや変更されたルールの影響を確認するためにルールを定期的にテストする手段となります。 既存の機能に影響を与える可能性のあるコード変更が行われた場合は、必ずテストケースを実行してください。 単体テストケースの使用方法についての詳細は、Pega Communityの記事「Understanding unit test cases」を参照してください。
ヒント： 保存されている単体テストをルールから自動的に実行することも、PegaUnitテストファシリティを使って単体テストを実行させることもできます。
テストケースを作成するには、「Run Rule」ウィンドウでテストを変換し、単体テストが成功したことを示す結果を定義します。 想定される結果はそれぞれ、1つ以上のテスト条件と各条件に対する期待される結果を記述するアサーションで構成されます。 テストケースは、ルール実行のさまざまな側面をテストするように複数のタイプのアサーションに対応しています。 テストケースで使用できるアサーションは、テストしたルールのタイプによって異なります。
補足： サポートされるアサーションのタイプとその用途の詳細な説明については、Pega Community記事「Defining expected test results with assertions」を参照してください。
次の表にアサーションとその用途の例を示します。
| 評価タイプ | 利用目的 | 例 |
|---|---|---|
| プロパティ | 指定されたプロパティの値をテストします。 プロパティが定義されているページ、比較演算、比較する値が必要です。 | pxUrgencyWork 10に等しい |
| デシジョンの結果 | デシジョンルールによって返される値をテストします。 デシジョンルールで想定される結果が返されるために必要な各入力プロパティの値が必要です。 | 「Referred by employee」が「false」の場合、「RecruitingWB」を返す |
| 想定される実行時間 | ルールが許容時間内に実行されるかどうかをテストします。 比較演算と許容時間（秒）が必要です。 | 想定される実行時間は3秒以内である |
| ページ | メモリー内でページの存在をテストします。 ページの名前と比較演算が必要です。 | ページ「D_CoursesList」にエラーがない。 |
想定される結果のセットを作成したら、テストケースの設定を保存します。 保存したテストケースには、ルールからアクセスできます。 ルールについて記録したすべてのテストケースと、各テストケースの最終実行時のステータスがリストに表示されます。 テストケースを再度実行し、失敗した場合は、結果を表示して、想定される結果を返さなかったアサーションを個別に特定します。 テストケースで想定される結果が返された場合は、緑色の「Passed」ステータスボタンが表示されます。
単体テストをテストスイートにまとめ、複数のテストケースとテストスイートを指定した順序で実行できます。 テストスイートを一括で実行すると、順次実行されますが、並列実行はされません。
テストケースの準備
テストケースを保存するには、テストケースの格納用に設定されているルールセットへのアクセス権が必要です。 テストケースの格納用に設定されていないルールセットには、テストケースを保存できません。
単体テストを記録する前に、システム管理者と連携して、テストケースを格納する適切なルールセットを確認してください。 テストは、他のテストケースに依存したり、後に実行されるテストに干渉したりしないよう、移動可能で独立した状態を維持してください。 開発したアプリケーションを本番環境にリリースする際は、テストケースを含めずにアプリケーションを移行できます。
ヒント： Cleanup機能を使用して、テスト実行中に発生したクリップボードのシステムページやデータ、ワークインスタンスへの変更を復元します。 「History」タブに変更履歴が表示されます。
テストケースの実行
Dev Studioの「Unit testing 」ランディングページには、アプリケーションに定義されているすべてのテストケースと、各テストケースの最終実行時のステータスがリスト表示されます。 ランディングページでは、関連する1つまたは複数のテストケースから構成されるテストスイートも作成できます。 Pegaの単体テストスイートを使って、複数のテストケースを指定した順序で実行できます。
ヒント： 「Configure 」メニューでApplication > Quality > Automated Testing > Unit Testing を選択すると、ランディングページにアクセスできます。
次の問題に答えて、理解度をチェックしましょう。
単体テストの設定に関するベストプラクティス
自動化された単体テストからは行動につながる結果が得られ、自動テストの実行と維持にかかる時間は手動テストにかかる時間よりも短縮されます。 Pega Platform™アプリケーションのルール開発と同時にテスト開発を行うようにします。 開発中にテストケースを再利用することも、他のチームがあなたのテストスイートを活用することもできます。
自動化単体テストを作成するタイミング
ルールが想定通りの結果を返した場合は、以下の優先順位表が示すように、自動化単体テストの設定を検討してください。
| 優先順位 高 | 優先順位 低 |
|---|---|
| 結果が予想できるテスト | テストケースのメンテナンスが必要な変更が頻繁に行われるテスト |
| 頻繁に実行する必要があるテスト | 手動で簡単に実行できるテスト |
| 複雑なロジックをテストする際に、手作業を軽減できるテスト | 複雑すぎて自動化できないテスト |
| アプリケーション全体で広く利用されているルールを含むテスト | データベースからのデータの永続化を含むテスト |
ヒント： 少なくともマージとチェックインのたびにテストを実行することが推奨されますが、理想的にはそれよりも頻繁に、定期的に実行することが推奨されます。
カバレッジを考慮した開発
単体テストは幅広いシナリオをカバーしているため、必ず十分な検証を作成して、好ましいシナリオと好ましくないシナリオすべてをカバーできるようにしてください。 ルールの実行経路が異なるものを含め、できるだけ多くのルールカバレッジを含めることを目指します。 すべての入力と出力の組み合わせをカバーする十分なテストを追加しますが、テストケースのロジックを短縮し、可視化して再利用性を最適化します。 規模の小さな単体テストは、ルール機能が動作しない場合にすばやく特定でき、設計やメンテナンスがしやすくなるようにします。
補足： ルールのテストカバレッジ測定の詳細については、Academyのトピック「Test coverage」を参照してください。
メンテナンスを考慮した開発
各テストケースは、誰にでも読みやすく、理解しやすくする必要があります。 たとえば、テストケースの名前と説明には関連性を持たせ、テストケースの目的がわかるようにします。 ステップごとにコメントをつけることで、読みやすくなり、メンテナンスもしやすくなります。
テストデータをできるだけモジュール化し、更新や将来の変更を簡単にすばやく行えるようにします。 たとえば、アプリケーション全体のテストデータや、より大規模で複雑なデータ構造のテストデータを作成する必要はありません。 テストデータのモジュール化が進めば、小さな変更でテストデータすべてを再構成する必要がなくなり、他のテストに問題が発生する可能性もなくなります。
このトピックは、下記のモジュールにも含まれています。
- アプリケーションのテスト v1
If you are having problems with your training, please review the Pega Academy Support FAQs.