この文章は Salesforce 機械翻訳システムを使用して翻訳されました。詳細はこちらをご参照ください。
英語に切り替える

拡張トランザクションセキュリティの Apex テスト

堅牢なテストを記述することは、コードが期待どおりに動作することを確認し、ユーザおよび顧客が実行する前にエラーを発見するためのエンジニアリング上のベストプラクティスです。トランザクションセキュリティポリシーの Apex コードは Salesforce 組織で重要なユーザアクションを実行するため、そのテストを記述することはさらに重要です。たとえば、テスト中 LoginEvent ポリシーのバグがキャッチされなかった場合、ユーザが組織から締め出される可能性もありますが、これは避けるべき状況です。
使用可能なインターフェース: Salesforce Classic および Lightning Experience
使用可能なエディション: Enterprise Edition、Performance Edition、Unlimited Edition、および Developer Edition

Salesforce Shield または Salesforce Event Monitoring アドオンサブスクリプションが必要です。


拡張トランザクションセキュリティポリシーの Apex テストを記述するときは、API バージョン 47.0 以降を使用します。

警告

一連の条件をシミュレートして Apex コードをテストする場合は、当然、単体テストを記述します。ただし、単体テストを記述するだけでは不十分です。ビジネスチームおよびセキュリティチームと協力して、あらゆる使用事例を理解してください。その後、Sandbox 環境のテストデータを使用して実際のユーザの体験を模した包括的なテスト計画を作成します。テスト計画には通常、手動テストと、Selenium などの外部ツールを使用する自動テストの両方が含まれます。

開始するために単体テストの例を見てみましょう。次の Apex ポリシーをテストするとします。

テストの計画および記述

テストの記述を開始する前に、テスト計画で対象とするプラスとマイナスの使用事例の概要を確認しましょう。

表 1. ポジティブテストケース
evaluate メソッドが受信した場合... かつ... evaluate メソッドが返す...
ApiEvent オブジェクト ApiEvent で Lead がその QueriedEntities 項目にあり、2000 より大きい数値が RowsProcessed 項目にある true
ReportEvent オブジェクト ReportEvent で Lead がその QueriedEntities 項目にあり、2000 より大きい数値が RowsProcessed 項目にある true
ListViewEvent オブジェクト ListViewEvent で Lead がその QueriedEntities 項目にあり、2000 より大きい数値が RowsProcessed 項目にある true
任意のイベントオブジェクト イベントで Lead がその QueriedEntities 項目になく、2000 より大きい数値が RowsProcessed 項目にある false
任意のイベントオブジェクト イベントで Lead がその QueriedEntities 項目にあり、2000 以下の数値が RowsProcessed 項目にある false
任意のイベントオブジェクト イベントで Lead がその QueriedEntities 項目になく、2000 以下の数値が RowsProcessed 項目にある false
表 2. ネガティブテストケース
evaluate メソッドが受信した場合... かつ... evaluate メソッドが返す...
LoginEvent オブジェクト (条件なし) false
null 値 (条件なし) false
ApiEvent オブジェクト QueriedEntities 項目が null である false
ReportEvent オブジェクト RowsProcessed 項目が null である false

次に、こうしたすべての使用事例を実装する Apex テストコードを示します。

テスト実行後のポリシーコードの調整

テストを実行し、testNullQueriedEntities テストケースが失敗してエラー System.NullPointerException: Attempt to de-reference a null object が起こったとします。幸い、テストで予期しない値または null 値をチェックしないトランザクションセキュリティポリシーの領域が明らかになりました。ポリシーは重要な組織の操作中に実行されるため、重要な機能がブロックされないようにエラーがある場合はポリシーが適切に失敗することを確認します。

こうした null 値を適切に処理する Apex クラスの evaluate メソッドを更新する方法を次に示します。

queriedEntities 変数で .contains 操作を実行する前に値が null かどうかを最初にチェックするように、コードを変更しました。この変更により、コードで null オブジェクトが参照解決されなくなります。

通常、Apex コードで予期しない値または状況に遭遇した場合、2 つのオプションがあります。
  • 値または状況を無視して、ポリシーがトリガしないように false を返す。
  • true を返して操作をフェイルクローズする。
どちらのオプションを選択するか決定するときは、ユーザに最適な方法を判断します。

高度な例

ログインしようとしているユーザのプロファイルを取得する SOQL クエリを使用するより複雑な Apex ポリシーを次に示します。

テスト計画は次のようになります。

  • ポジティブテストケース
    • ログインしようとしているユーザのプロファイルを監視したい場合は、evaluate メソッドが true を返す。
    • ログインしようとしているユーザのプロファイルを監視したくない場合は、evaluate メソッドが false を返す。
  • ネガティブテストケース
    • 例外を発生させるプロファイルオブジェクトのクエリを行う場合は、evaluate メソッドが false を返す。
    • null を返すプロファイルオブジェクトのクエリを行う場合は、evaluate メソッドが false を返す。

すべての Salesforce ユーザに必ずプロファイルが割り当てられるため、そのネガティブテストを作成する必要はありません。2 つのネガティブテストケースに実際のテストを作成することもできません。これについては、ポリシー自体を更新することで Salesforce が行います。ただし、計画で使用事例を明示歴にリストし、さまざまな状況に対応できるようにします。

ポジティブテストケースは、SQQL クエリの結果のみに依存します。これらのクエリが正しく実行されるようにするために、テストデータも作成します。テストコードを見てみましょう。

プロファイルオブジェクトのクエリを行うときに例外または null の結果をチェックするようにトランザクションセキュリティポリシーコードを更新して、2 つのネガティブテストケースを処理しましょう。