HOW TO TEST CODE COVERAGE IN SALESFORCE (USEFUL TIPS AND TECHNIQUES)
Salesforce には、クライアントの要件に合わせてカスタマイズできる、すぐに使える多くの機能が備わっています。Salesforce でのテストには、基本的な Salesforce 組織での構成とカスタマイズの検証が含まれます。ただし、Salesforce 全体ではなくカスタム コードのみをテストする必要がある場合、このテストは非常に困難です。
まず、テストを行う際の主な目的を理解することが重要です。
- コードの機能を確認します。
- 展開前に変更を確認します。
- システムがクライアントの要件を満たしていることを確認します。
- エラー/バグを早期に特定します。
- 機能フローを作成して確認します。
テストは、QA チームが単体テスト、統合テスト、回帰テスト、およびシステム テストを処理する手動で処理することも、Selenium、Assure Click、QTP などのツールを使用して自動的に処理することもできます。
このプロセスは、テスターが変更内容を明確に理解している他の Web ベースのアプリケーションと似ています。開発者とテスターはサンドボックス環境を使用し、そこからテストされたコードが本番環境にデプロイされます。
テストカバレッジ
プロジェクトに取り組んでいるときに、コードの現在のステータスを知るためにテスト クラスのカバレッジを引き出す必要がある状況によく遭遇します。
テストは、ソフトウェア開発ライフ サイクル (SDLC) の重要な部分です。コードを本番環境に移行する前に、Salesforce はコードのカバー率が 75% 以上であることを確認します。これは、コードをテストし、本番環境で壊れないことを意味します。
クラスのコード カバレッジをテストするには、さまざまな方法があります。
- 次のコマンドを実行するだけで、Salesforce CLI を使用して Apex コード カバレッジを取得できます。
sfdx force:apex:test:run –codecoverage –resultformat human
2. 開発者コンソールの使用
以下の手順に従って、集計コード カバレッジの詳細を取得します。
を。セットアップ -> Apex テストの実行 -> オプションをクリック -> 「集計されたコード カバレッジのみを保存」のチェックを外します。
セットアップ -> Apex テスト実行 -> 「テスト履歴を表示」をクリックし、すべてのテスト履歴をクリアします。
抽出に進む前に、まずすべてのクラスをコンパイルしてエラーの可能性を排除し、次にすべてのテストを実行する必要があります。この時点で、失敗しているクラスを特定し、それらの別のリストを作成できます。
c. [設定] -> [Apex クラス] -> すべてのクラスをコンパイルします。
クラスがコンパイルされたので、次の場所に移動して、組織の全体的なコード カバレッジを確認できます。
[設定] -> [ApexClasses] -> [全体的なコード カバレッジを計算]
それでも結果に自信がない場合は、Tooling API を含む以下の手順に従うことができます。
3. 上記のクラスのコンパイルを実行します。
どのクラスのカバレッジが低いかを知るには、役立つ簡単なプロセスがあります。
Google Chrome を使用している場合は、次の拡張機能をインストールします。
SDFC デベロッパー コンソール データ エクスポーター
完了したら、開発者コンソールに移動して、必要なフィールドのクエリを作成する必要があります。
たとえば、次のクエリを使用できます。
SELECT ApexClassOrTrigger.Name、NumLinesCovered、NumLinesUncovered、LastModifiedDate、CreatedDate、CoverageLastModifiedDate、CreatedBy.nameFROMApexCodeCoverageAggregate
ここで、ApexCodeCoverageAggregate は、Apex クラスまたはトリガのコードカバレッジテスト結果を表します。
次の API 呼び出しをサポートしています: describeSObjects()、query()、retrieve()
対象となるフィールド: ApexClassorTriggerId、NumLinesCovered、NumLinesUncovered、Coverage
次に、ツール API を使用します。
しかし、いつそれを使うべきかをどうやって知るのでしょうか?
組織のメタデータへのきめ細かいアクセスが必要な場合は、Tooling API を使用します。多くのメタデータ型に対する Tooling API の SOQL 機能を使用すると、より小さなメタデータを取得できます。取得を小さくするとパフォーマンスが向上するため、Tooling API は対話型アプリケーションの開発により適したものになります。
Dev コンソールで Use Tooling API チェックボックスがオンになっていることを確認する必要があります。
クエリを実行した後、ブラウザーの右上隅にある拡張子を確認して選択すると、ダウンロード用の csv ファイルがポップアップ表示されます。
ファイルをダウンロードすると、次の単純な式を使用して、カバレッジの高低をさらに分析する準備が整います。
=(NumLinesCovered/(NumLinesCovered+NumLinesUncovered))*100
これにより、コード カバレッジのパーセンテージと、運用環境に移行する前にどのクラスに取り組むべきかを確認できます。通常、大きなプロジェクトに取り組む場合、開発組織、テスト組織など、多くの組織が関与します。より上位の組織への展開は、特定の人または個人 (リリース マネージャー) によって行われます。カバー率の低いテスト クラスは、作成者と同じ担当者に割り当てて再作業することをお勧めします。
次の 2 つの簡単な手順で、クラスの実際の作成者を特定できます。
- さまざまなクラスに対して Dev から作成者名を抽出します。開発組織に対して ApexCodeCoverageAggregate から同じクエリを実行し、Excel ファイルを抽出できます。
- 上位組織の Excel データと Dev 組織のデータに対して Vlookup を実行し、作成者の名前を抽出します。
VLOOKUP 関数には 4 つのコンポーネントがあります。
- 調べたい値。
- 値を検索する範囲。
- 定義した範囲内の列の番号。
- 探している値と完全に一致する場合は 0 または FALSE。近似一致の場合は 1 または TRUE。
構文: VLOOKUP([値], [範囲], [列番号], [偽または真])
本番環境でコード カバレッジ数を照合するための推奨プロセス
テスト カバレッジが重要な理由とそのデータを収集する方法を理解したところで、本番用のコード カバレッジ数を照合するための推奨プロセスを見ていきましょう。
- 本番展開に使用するステージング サンドボックス環境に似たフル サンドボックスを使用できます。フル サンドボックスは、本番環境のメタデータとデータを模倣し、2 つの環境間のコード カバレッジ数の違いを減らすのに役立ちます。
- テスト データを使用して、サンドボックス環境と運用組織のデータへの依存を減らすことができます。
- デプロイが本番環境に失敗した場合、コード カバレッジを増やすために、より全体的なテスト ケースを作成する必要があります。目標は、カバレッジを 100% に上げてから、展開を再試行することです。
- 展開がまだ失敗する場合は、本番組織からローカル テストを実行する必要があります。カバー率が 75% 未満のテスト ケースを特定し、それらのクラスに追加のテストを記述して、コード カバー率を上げる必要があります。
コード カバレッジの一般的なヒント:
- 常にコード カバレッジの新しいプルを取得します。テストが実行されない限り、組織内の Apex コードが更新されても、コード カバレッジの数値が更新されないことがあります。
- 前回のテスト実行後に組織が更新された場合は、Apex テストを再実行して、コード カバレッジの正確な見積もりを取得します。
- 組織の全体的なテスト カバレッジには、管理パッケージ テストが含まれていないことを知っておく必要があります。管理パッケージのテストによってトリガーが起動されると、例外が発生する場合があります。RunAllTestsInOrg テスト レベルですべてのテストを実行した後にデプロイで計算されたコード カバレッジには、管理パッケージ コードのカバレッジが含まれます。RunAllTestsInOrg テスト レベルを介して展開で管理パッケージ テストを実行している場合は、最初にこの展開をサンドボックスで実行するか、検証展開を実行してコード カバレッジを確認することをお勧めします。
- コード カバレッジはコードの総行数に依存することがわかっているため、コードの挿入または削除があると、コードの割合に影響します。たとえば、ある組織に、テスト メソッドでカバーされる 50 行のコードがあるとします。テストでカバーされていない 50 行のコードを含むトリガーを追加すると、コード カバレッジのパーセンテージは 100% から 50% に低下します。トリガーにより、組織内の合計コード行が 50 から 100 に増加しますが、そのうちの 50 のみがテストでカバーされています。