AppExchange アプリケーションのテスト

学習の目的

この単元を完了すると、次のことができるようになります。

  • Apex を使用する場合のテストカバー率要件を挙げる。
  • AppExchange アプリケーションの作成時に実行する特定のテストについて説明する。
  • セキュリティレビューに合格するためにテストで対処する必要のあるセキュリティの脆弱性の種類を挙げる。

テストと AppExchange アプリケーション

あなたがテストの重要性を認識していることは重々承知しています。この単元では、テストにまつわる Salesforce 独自のいくつかの条件と、あなたにとってより重要なテストに関する AppExchange の一定の要件について簡単に説明します。

Apex のテストフレームワーク

Apex には、どの開発者にとっても不可欠なテストフレームワークが組み込まれています。Salesforce では、このフレームワークを使用して、配分を超えるリソースを使用しているコードがないよう確認する必要があります。

基本的な要件は、テストでパッケージ内のすべての Apex コードの 75% 以上をカバーすることです。実際には、カバー率をできるだけ 100% に近づけることをお勧めします。その他の要件については、Trailhead の「Apex テスト」モジュールまたは『Apex 開発者ガイド』の「Apex のテストについて」セクションを参照してください。パッケージをアップロードするたびに、すべてのテストが実行されます。テストに 1 つでも失敗すれば、アップロードも失敗します。

プラットフォームの潜在的な問題

コーディングの手法がお粗末であれば、単一の組織内では何とかなったとしても、AppExchange アプリケーションが失敗する原因になります。最も一般的な問題のいくつかは、ハードコードされた値に起因します。特に次のものは絶対にハードコードしないでください。

  • 組織全体で一意のレコード ID
  • 顧客が変更可能な値 (選択リスト値やレコードタイプ名など) への参照

また、顧客がプラットフォームの暗号化を実行する可能性があることも考慮します。アプリケーションで重視する標準オブジェクトの標準項目を記録します。プラットフォームの暗号化を使用する顧客をサポートする場合は、これらの標準項目が暗号化されたときにアプリケーションが破損しないことをテストします。このテストに合格したら、AppExchange でこのアプリケーションに「暗号化項目をサポート」と表示することができます。詳細は、ヘルプの「プラットフォームの暗号化」およびトレーニング教材を参照してください。

毎日のテスト

すべてのコードを毎日マージすることを標準的な実務として、変更や追加によって既存のコードが破損しないか確認することをお勧めします。

ソース制御システム (1) を設定し、開発者が作成または変更したメタデータファイルを自身で確認できるようにするとよいでしょう。そして、毎日このソース制御システムからメタデータをパートナー開発者共有組織 (2) に転送し、アプリケーションに対する自動テストを実行します。

開発者組織からソース制御システム、1 つの開発者組織へと順次フィードされる図

あらゆるソフトウェアの開発と同様に、テストでは次の点を検証します。

  • Apex コードが正常に機能し、すべてのテストに合格し、テストの要件を満たすこと
  • カスタム UI が期待どおりに表示され、応答すること
  • ビジネスロジックが要件を満たし、余計な動作を行わないこと

リリース前のパッケージテスト

アプリケーションはパッケージに入れて顧客に配布されるため、AppExchange パートナーのリリーステストには、パッケージ化された状態のアプリケーションのテストも含まれます。パッケージが正しくインストールされていること、インストール後にすべての機能が期待どおり動作することなどを確認できます。

承認プロセスなど少数のコンポーネントはパッケージ化できません。必要な設定をすべて文書化し、その設定手順の確認をテストに含めます。

パッケージの後続のバージョンをリリースするときは、既存の顧客がアプリケーションの新しいバージョンをインストールできることもテストで確認します。新しいバージョンが、新規の組織と旧バージョンが搭載された組織の両方で機能することを確認します。

「管理-ベータ」パッケージ

最初のパッケージテストは、「管理-ベータ」パッケージから行います。アプリケーションがベータパッケージに含まれている間は、どのような変更も実行できます。

ベータパッケージの使用の流れは、次のとおりです。

  1. 変更をソース制御システムからベータパッケージ組織に転送します。
  2. アプリケーションを含む「管理-ベータ」パッケージを作成します。
  3. パッケージをアップロードします。
  4. テスト組織で、
    1. パッケージをインストールしてテストします。
    2. 問題が見つかった場合は、
      1. テスト組織のパッケージをアンインストールします。
      2. PDE 組織でアプリケーションを更新します。
      3. ソース制御システムに変更をチェックインします。
      4. ソース制御システムからベータパッケージ組織に更新を転送し、必要に応じて「管理-ベータ」パッケージの内容を編集します。
      5. ステップ 2 に戻ります。
    3. 問題が生じず、開発が完了したら、「管理-リリース済み」パッケージに進みます。

構築およびテストサイクル中に、テスト組織のベータパッケージをアンインストールして、新しいベータパッケージをインストールします。ベータパッケージはアップグレードできないため、1 つのベータパッケージのバージョンの上に別のバージョンをインストールすることはできません。詳細は、「パッケージのアンインストール」および「パッケージのインストール」を参照してください。

名前空間に対する注意事項

アプリケーションがパッケージ化されたら、名前空間を正しく使用していることを確認します。アプリケーション内のコンポーネントへの JavaScript 参照が、自動的にパッケージの名前空間に更新されることはありません。Visualforce ページ上でも (JavaScript を使用する) Lightning コンポーネント内でも、JavaScript を伴うすべてのカスタマイズが引き続き正しく機能することを確認します。

セキュリティの確保

アプリケーションを AppExchange に公開する前に、セキュリティレビューを受ける必要があります。開発サイクルを通して、要件チェックリストに挙げられているものなど、セキュリティ上の問題に対処します。

このチェックリストには、次の点を検証する項目が記載されています。

  • コードが、組織の Salesforce システム管理者によって指定された項目レベルおよびオブジェクトのセキュリティを遵守している。この点は、セキュリティレビューで多数のアプリケーションにフラグが設定される原因となっているため、細心の注意を払います。
  • クロスサイトスクリプト (XSS) 攻撃を阻止する JavaScript および HTML を記述している。
  • プラットフォームの内外でデータを送信するときや、機密情報 (ログイン情報や顧客データなど) をプラットフォーム外に保存するときに暗号化を実装する。

セキュリティレビューでは、アプリケーションに対して数種類のテストが実行されます。アプリケーションを申請する以前にもいくつかのテストを実行できます。こうしたテストを各自のテストサイクルに取り入れてください。

パッケージ化および顧客の変更

パッケージをアップロードするときに、アプリケーションを正常にインストールするために顧客の組織が満たす必要のあるパッケージ要件やオブジェクト要件を設定できます。今ここで何を選択すべきかわからなくても心配いりません。場数を踏めば慣れてきます。また、選択を誤っても大事に至る可能性は低く、通常はデフォルトで問題ありません。

パッケージ要件画面

オブジェク要件画面

値の中には、パッケージの内容に基づいて自動的に有効になるものがあります。画面のリストの値がアプリケーションにとって正しいものであることを確認し、パッケージのインストール時にエラーが発生しないようにします。

たとえば、Chatter 関連のコンポーネントやコミュニティが自動選択されていることがありますが、顧客の組織でこれらの機能が無効になっている場合、パッケージをインストールしようとしたときに失敗します。

「管理-リリース済み」パッケージ

パッケージ化された状態のアプリケーションに一切バグがないと思われる場合は、ベータパッケージ組織で「管理-リリース済み」パッケージの作成を開始します。リリース済みパッケージの作成はごく簡単で、パッケージをアップロードするときにオプションを選択するだけです。

「管理-リリース済み」パッケージを作成するラジオボタンを示す画面

そして、パッケージをテストの第 2 弾に送信します。

アプリケーションの一番大切なパッケージの作成

ここまで問題がなければ、一番大切なパッケージ組織の使用に進みます。

  1. 移行ツールを使用して、アプリケーションを一番大切なパッケージに移します。
  2. 顧客に表示する名前空間を設定します。
  3. コンポーネントをパッケージにまとめます。
  4. 「管理-リリース済み」パッケージを作成します。
  5. そして、ここでテストの第 2 弾を実行します。

すべて終了したら、アプリケーションのセキュリティレビューを申請します。セキュリティレビューに合格すれば、いよいよ販売です。

まとめ

プラットフォーム上のほとんどのテストは、標準的なベストプラクティスに従います。テストでは、次の点を判定します。

  • 機能要件を満たしている。
  • コードを検証するテストを記述している。
  • セキュリティの脆弱性に対処している。

パッケージをテストするときは、次の点も検証します。

  • 外部コードが名前空間を正しく参照している。
  • インストール手順
  • パッケージ要件およびオブジェクト要件

これで終了です。これで、アプリケーションを開発する AppExchange パートナーツールの使用に関する基本をすべて習得することができました。前進を続け、知識を増やし、この素晴らしいアプリケーションを記述してください。

リソース

無料で学習を続けましょう!
続けるにはアカウントにサインアップしてください。
サインアップすると次のような機能が利用できるようになります。
  • 各自のキャリア目標に合わせてパーソナライズされたおすすめが表示される
  • ハンズオン Challenge やテストでスキルを練習できる
  • 進捗状況を追跡して上司と共有できる
  • メンターやキャリアチャンスと繋がることができる