Salesforce統合をテストするためのヒントとベストプラクティス

セールスフォースの統合

Salesforceテストは、カスタマイズしたものを検証するのに役立ちます Salesforceの統合 および他のエンタープライズアプリケーションとの機能。 優れたテストは、アカウントからリード、商談からレポート、キャンペーンから連絡先まで、すべてのSalesforceモジュールを対象としています。 すべてのテストの場合と同様に、Salesforceテストを実行するための良い(効果的かつ効率的な)方法と悪い方法があります。 では、Salesforceテストのグッドプラクティスとは何ですか?

  • 適切なテストツールを使用する – Salesforceのテストは、ブラウザまたは日食ベースの環境で行われます。 最新のブラウザーとEclipseの両方に優れたデバッグツールがあり、これらをテストクラスと組み合わせて非常に役立つ結果を得ることができます。 ただし、さらに必要な場合は、Force.comのApex Interactive Debugger(または単にApex)を使用する必要があります。 Chrome拡張機能であるSalesforceLightning Inspectorを使用して、SalesforceLightningを具体的にテストすることもできます。 エイペックスは Force.com Javaとの大きな類似性を持つプラットフォーム独自のプログラミング言語。 これは、中括弧とドット表記構文に従う、オブジェクト指向で大文字と小文字を区別しない、厳密に型指定されたプログラミング言語です。 Apexを使用して、カスタムリンクとボタン、更新、削除、Visualforceページのカスタムコントローラーまたはスケジューリングを介したレコード挿入イベントハンドラーなど、ほとんどのForce.comプロセス中にプログラムされた機能を実行できます。
  • 適切な命名規則を使用する– テストの作成を開始する前に、テストメソッドに適切な名前を付けることが非常に重要です。 テストメソッド名はXNUMXつの部分で構成されている必要があります。 これらはnameOfMethod(トリガーをテストするときの挿入/更新/削除/削除解除などのテストする個々のメソッドの名前、連絡先がnullであることをテストする場合はnull連絡先などの柔軟なTestPathに関する情報、テスト時に有効)です。正/負のパス。
  • 100%のカバレッジを確保– 標準のSalesforceディレクティブでは、単体テストはコードの75%(テストクラス、System.debugの呼び出し、およびテストメソッドを除く)をカバーする必要があり、ApexコードをデプロイしたりAppExchangeアプリをパッケージ化したりすることはできませんが、これは単なる標準であり、100%のカバレッジを目標にする必要があることに注意してください。 すべてのポジティブ/ネガティブケースをテストし、存在するデータと存在しないデータをテストします。 コードカバレッジに関するその他の重要なヒントは次のとおりです。
    • Apexコードが更新されてもテストが再実行されるまでこれらの数値は更新されないため、テストを実行してコードカバレッジ番号を更新する必要があります。
    • 前回のテスト実行以降に組織が更新された場合、コードカバレッジ番号が正しくなくなるリスクがあります。 正しい見積もりの​​ためにテストを再実行します。
    • コードカバレッジの割合には、マネージパッケージテストのコードカバレッジは含まれていません。ただし、これらのテストによってトリガーが起動する場合を除きます。
    • カバレッジは、コード行の総数によって異なります。 コード行を追加または削除すると、パーセンテージに影響します。
  • クラスとコントローラーのテストケース– Salesforce開発では、ほとんどの開発者が関数ごとに個別のクラスとコントローラファイルを作成します。 これは、コーディングをより整理され、より簡単に、再利用可能で、移植可能にするために行われます。 ただし、これは簡単ですが、効率的ではないことに注意してください。 サンドボックスから本番環境に移行するときにテストクラスを見逃すことはないため、テストコードが元のクラスとコントローラーコード自体にある場合は、移植性が得られます。
  • System.assert()を使用する– アペックスでは、 System.assert()は条件の確認に使用します。 これは、特定の機能が期待どおりにメソッドによって実行されたかどうかを判断できるため、重要な機能です。 重要な機能間でSystem.assertEquals()とSystem.assertNotEquals()を使用することは、コードが正常に実行されたかどうかを判断するのに役立つだけでなく、コードが間違った場合にデータが誤って書き込まれないようにするのにも役立ちます。
  • 総合試験 –テストはすべてをカバーする必要があります。 機能テスト、負荷テスト、セキュリティテスト、および展開テストを実行する必要があります。
  • ユニットテスト– 個々のレコードが正しく期待される結果を生成することを確認するために、単体テストが必要です。 コード全体をカバーする巨大なテストを使用することは良い考えのように思えるかもしれませんが、生成された結果はデバッグが難しく、失敗は理解しにくいことに注意してください。 単体テストは、テストされる機能の小さなサブセットをカバーする必要があります。
  • バルクケースのテスト– 優れたテストコード(トリガー、例外、またはクラス)は、最大数百のレコード(Apexの場合は200)に関係する可能性があります。 これを利用して、個々のレコードだけでなく、バ​​ルクケースもテストする必要があります。
  • ポジティブテスト– 予想されるすべての順列を通じて予想される動作が発生するかどうかを確認するためにテストします。 テストでは、ユーザーがフォームに正しく入力したこと、およびユーザーが制限を超えていないことを確認する必要があります。
  • ネガティブテスト– ネガティブケースをテストして、エラーメッセージが正しく生成されることを確認します。 このようなネガティブなケースの例としては、ネガティブな金額を指定できないことや、将来の日付を追加できないことが挙げられます。 物事が南に行くときの正しい取り扱いがすべての違いを生むことができるので、否定的なテストは重要です。
  • テストの自動化– 従来、Salesforceのテストは手動で行われました。 自動テストはより多くの利点を提供するため、検討する必要があります。 これらには以下が含まれます:
    • テストはロボットではなく人間によるものであるため、手動テストでは間違いが発生しやすくなります。 ロボットは繰り返しの活動に優れていますが、人間は退屈、集中力と一貫性の低下、および手抜きをする傾向があるために間違いを犯します。
    • 手動テストは反復的で、定型的で、疲れます。 テストチームは、より探索的な作業を行う方がよいでしょう。
  • 各コードロジックブランチを実行する– 条件付きロジックを使用する場合(三項演算子を含めた場合)、コードロジックの各ブランチを実行する必要があります。
  • メソッドの呼び出しに無効で有効な入力を使用する– メソッドの呼び出しは、無効な入力と有効な入力の両方を使用して行う必要があります。
  • 完全なテスト– テストが正常に完了することを確認します。エラーが予想されない限り、例外を通過してはなりません。 キャッチされたすべての例外を処理します–それらをキャッチするだけでは十分ではありません。
  • ORDER BYキーワードを使用する– レコードが期待どおりの順序で返されるようにするには、ORDERBYキーワードを使用します。
  • レコードIDが順番に配置されていると想定しないでください– レコードIDが順番に配置されていると想定するというよくある間違いを避けてください。 同じリクエストで複数のレコードを挿入しない限り、IDは昇順ではありません。
  • Test.startTest()およびTest.stopTest()を呼び出す– Apex単体テストを実行すると、Salesforceで必須の75%を超えるコードカバレッジが得られます。 アサーションの前にstopTestを呼び出して、まだ実行されている可能性のある非同期コードを強制的に終了する必要があります。 他のコードがデータを変更する可能性があるため、最終結果に対して新しいクエリを実行します。 Test.startTest()とTest.stopTest()を使用すると、ガバナ制限内でテストをサンドボックス化できます。 このように、使用するセットアップコードは干渉せず、ガバナ制限を取り巻くフォールスネガティブまたはポジティブを提供します。 Test.stopTest()は、@ future呼び出しがテストのために完了することも保証します。
  • 読みやすさ– ユニットテストでは、読みやすさが非常に重要です。 テスト名には、実行する特定のアクションと期待される結果を含める必要があります。 メソッドは説明的で短くする必要があります。 この方法は、さまざまなテストで再利用できるようにする必要があります。
  • startTestの前に大規模なテストデータセットを構築する– テストはさまざまなサンドボックス環境と本番環境で実行されるため、startTestを呼び出す前に大規模なテストデータセットを作成して、テストに完全な実行制限があることを確認してください。 デフォルトでは、 Salesforce GitHub 本番データから分離されたテストを実行します。 プロファイルなどのシステムデータが必要な場合は、クエリを実行して、その特定の環境に適したものを取得します。
  • 独自のテストデータを生成する– 使用するテストデータは、テストで生成する必要があります。 @testSetupアノテーションとTestUtilsクラスを使用してこのデータを生成すると、正しいデータがあることを確認できるだけでなく、データを必要とせずにすべてのテストが開発者サンドボックスで実行されることを確認できます。
  • no-op AKA null操作を回避する– 多くのテスターは、no-op AKAnull操作を使用します。 これらは何もしない役に立たないコードです。 それらはすでにコードベースにあるため、カバレッジ率に追加されます。
  • 並列テストの実行– Salesforceユーザーインターフェイスまたは開発者コンソールからテストを開始すると、テストは並行して実行されます。 これは、テストの実行時間を短縮するための重要な機能です。 ただし、これによりデータ競合の問題が発生する可能性があることに注意してください。これが発生する可能性があると思われる場合は、並列実行をオフにしてください。 UNABLE_TO_LOCK_ROWエラーにつながることが多いデータ競合の問題の最も一般的な原因は次のとおりです。
    • テストが同じレコードを同時に更新することを意図している場合。 同じレコードの更新は通常、テストが独自のデータを作成しない場合に発生します。
    • 並行して実行されているテストにデッドロックがあり、それらが一致するインデックスフィールド値を持つレコードを作成しようとした場合。 デッドロックは、実行中の2つのテストがデータをロールバックするためにキューに入れられた場合に発生します(これは、2つのテストが異なる順序で同じ一意のインデックスフィールド値を持つ入力レコードを入力した場合に発生します)。
    • 並列テストの実行をオフにするには、[セットアップ]に移動し、Apex Testと入力し、[Apex Test Execution Options]ダイアログに移動して、[Disable Parallel Apex Testing]を選択し、[OK]をクリックします。

ParallelApexテストを無効にする

彼は良いテストを行うために必要な経験とトレーニングを持っているので、仕事のためにプロを雇ってください、そしてそれはあなたに安心を与えます。 プロを雇うことであなたはあなたのコアビジネスに集中することができます。 また、仕事のために社内チームを必要としないため、コストを節約できます。

どう思いますか?

このサイトはAkismetを使用して迷惑メールを減らします。 コメントの処理方法を学ぶ.