コードカバレッジの手順とデプロイ前の考慮事項

対象の組織にデプロイする前に、どのようにしてコードカバー率を正確に計算するのですか？

1. 対象の組織でテスト履歴をクリアします ([設定] | [開発] | [Apex テスト実行] から [テスト履歴を表示] リンクをクリックし、[テストデータをクリア] をクリックします)。

注: [テストデータをクリア] ボタンは次の 2 つのアクションを完了します:
i) ApexCodeCoverage テーブルからすべてのエントリを削除します
ii) ApexCodeCoverageAggregate テーブルのすべてのエントリをリセットし、0 行をカバーし、すべての行を Uncovered としてマークします。
これにより、組織のコードカバー率の見積もりが 0% になります。

2. すべてのテスト履歴を完全にクリアされました。すべての Apex クラスは、ユーザインターフェースの [すべてのクラスをコンパイル ] リンクから再コンパイルする必要があります ([設定] | [開発] | [Apex クラス] | [すべてのクラスをコンパイル ])。

3. すべてのクラスが再コンパイルされたら、すべてのテストをユーザインターフェースの [Run All Tests] ボタン( [設定] | [開発] | [Apex クラス] | [Run All Tests] ボタンをクリック) を使用して再度実行する必要があります。

注: ユーザインターフェースで [Run All Tests] ボタンをクリックすると、現在の組織内のすべての Apex テストが実行されます。 このボタンは、ページに適用されたフィルタ(ビュー) を考慮しません。

4. すべてのテストが完了したら、ユーザインターフェースの [組織のコードカバー率を見積る] リンクを使用して、対象組織のコードカバー率の見積もりを実行します ([設定] | [開発] | [Apex クラス] | [組織のコードカバー率を見積る])

5. 見積もりの結果をメモします。

6. これらの結果を「ApexOrgWideCoverage」テーブルから確認するため、開発者コンソールで [Query Editor] タブの [Tooling API] を使用して次のクエリを実行します。

SELECT PercentCovered FROM ApexOrgWideCoverage

7. 再びカバー率をメモしてください。うまくいけば、ステップ 7 で得られた見積もりとステップ 8 で記録する内容が一致するはずです。

8. ソース Sandbox 組織で「ダミーの」デプロイ検証を実行し、Apex コードを含まない単純な変更セットを作成することで、これらのコードカバー率の結果の精度をさらに検証することができます。 この「ダミーの」変更セットには、ドキュメント (https://developer.salesforce.com/docs/atlas.ja-jp.api_meta.meta/api_meta/meta_deploy_running_tests.htm) に記載されているように、すべてのテストを強制的に実行するコンポーネントが含まれている必要があります。たとえば、カスタム項目などです。

9. Apex コードを含まないこの変更セットがソース組織の送信変更セットとしてアップロードされたら、対象組織の受信変更セットにてこの変更セットの「検証」を実行します。

10. 検証の結果を確認します。新しい Apex コードや修正された Apex コードを含まない変更セットを検証しているため、コードカバレッジは対象組織のコードとしてすでに存在するものからのみ算出されるはずです。この「ダミーの」変更セットの検証結果の予想は、上記ステップ 8 および 10 で確認した結果と一致するはずです。結果が75%未満であれば、この変更セットはコードカバレッジ違反により検証に失敗することが予想されます。75%以上であれば、検証に成功することが予想されます。前述の通り、この変更セットは新規/修正コードをデプロイしないため、対象組織の既存のコード上のカバレッジのみを考慮する必要があります。

11. 上記の手順をふまえて、対象組織内のコードカバー率の現在の状態を正確に把握します。


新しいコードをデプロイすると、デプロイ時のコードカバー率にどのように影響しますか？

1. 新しい Apex コードのデプロイでは、対象組織の既存のコード上 (上記の手順) からのカバー率と、デプロイされる新しいコードのカバー率を使用してカバー率が計算されます。大幅にカバーされた新しいコードをデプロイする場合は、Apex コードを含まない変更セットで、上記で確認したものよりも全体的なカバー率が増加することが見込めますが、確認された全体的なは、この大幅にカバーされた新しいコードがどの程度のものであるかによって、全体的な増加は予想よりも少ない可能性があります。

もし以前に、Apexコードを含まない最初の変更セットがカバレッジの低さにより失敗していた場合、新しいコードを含む2回目の試みでも変更セットが失敗する可能性がありますが、カバレッジの増加が見られるはずです。増加の度合いは、新しいクラスのサイズとカバレッジ率に依存します。もし、説明した通りに増加が見られた場合、すべて順調であると思われますので、ソース組織にさらに多くのカバレッジを記述し、それを変更セットにデプロイして、75%の閾値ラインを超えるようにします。

たとえば、10,000 行カバーされた (上記の手順 1 - 11 で判断されます) 70%のカバー率の対象組織へ、新たに 100 行カバーされた 95% のカバー率の新しい Apex クラスをデプロイする場合、この新しいクラスのデプロイに関する次の全体的なコードカバレッジは、次のように計算できます。

仮定:

n1 はカバーする既存の行数、
n2 はカバーされている既存の行数、
n3 は、カバレッジを必要とする最終的な新しい行数であり、
n4 はカバーされた最終的な新しい行数です。

そして、n2/n1 は 70% になり、n4/n3 は 95% になりますが、新しいコードカバー率は (n2+n4)/(n1+n3) となります。「カバーされた (新規および既存の) 行の合計は、カバーする (新規および既存の) 行数の合計で除算されます。」

したがって、n1=10,000、n2=7,000、n3=100、および、n4=95 の場合、新しいコードカバー率は (95+7,000)/(10,000+100)=70.25% となります。

2. これは、新しいコードを含む変更セットの検証を実行することによって、再度テストすることができます。手順 1 - 14 での対象組織の既存のコードベースに関する手順と分析を既に行っていると仮定して、ソース Sandbox 組織では、100 行 で 95% カバーされた、この新しい Apex クラスのみを含む単純な変更セットを作成します。

3. この変更セットがソース組織の送信変更セットとしてアップロードされたら、対象組織の受信変更セットでこの変更セットの「検証」を実行する必要があります。

4. 以前の例を考えてみると、対象組織の既存のコードベースで 70% のカバー率しかない場合、この新しいクラスをデプロイすると全体のカバレッジは 70.25% に増加するはずですが、コードカバレッジ違反によりデプロイが失敗します。前述のように、追加のコードカバレッジを作成し、これをデプロイ変更セットに含め、このデプロイを 75%のしきい値を超えるようにする必要があります。恐らく、実際の 70% の値は低すぎるので、既存のコードペースのカバーされていないコードをカバーするために、新しいテストメソッドを含めるかもしれません。


トラブルシューティングの際の追加のコードカバレッジの考慮事項

• すべてのテストがパスし、少なくとも 1% のカバー率がすべてのトリガに適用されていることを確認します。
• 前回のデプロイ後に対象組織のカバー率が低下した場合は、上記の手順を実行し、履歴をすべてクリアします。データまたはメタデータの依存関係が原因である可能性があるため、@isTest (SeeAllData = true) を使用するためのすべてのテストクラスをレビューします。
• これらのクラスのデフォルトは @isTest (SeeAllData = true) を使用するため、API バージョン 23.0 以下を使用してテストクラスを特定します。

追加情報

• Testing and Code Coverage

• Code Coverage Best Practices

• Get accurate code coverage from Metadata API

• Salesforce Developers Blog - How Code Coverage Works