測試Salesforce集成的提示和最佳做法

Salesforce整合

Salesforce測試將幫助您驗證定制的 Salesforce集成 以及其他企業應用程序的功能。 良好的測試涵蓋了所有Salesforce模塊,從客戶到潛在客戶,從機會到報告,從活動到聯繫人。 與所有測試一樣,執行Salesforce測試有好(有效)的方法,還有不好的方法。 那麼,Salesforce測試的最佳做法是什麼?

  • 使用正確的測試工具 – Salesforce測試在瀏覽器或基於Eclipse的環境中進行。 最新的瀏覽器和eclipse都具有出色的調試工具,您可以將它們與測試類結合使用以獲得非常有用的結果。 但是,如果您需要更多,則應使用Force.com的Apex交互式調試器(或簡稱為Apex)。 請注意,您還可以使用Salesforce Lightning Inspector(鍍鉻擴展程序)專門測試Salesforce Lightning。 Apex是一個 原力網 與Java極為相似的平台專有編程語言。 它是一種面向對象的,不區分大小寫的強類型編程語言,遵循花括號和點符號語法。 您可以在大多數Force.com流程中使用Apex執行編程功能,包括自定義鏈接和按鈕,更新,刪除以及通過Visualforce頁面自定義控制器或計劃記錄插入事件處理程序。
  • 使用正確的命名約定– 在開始編寫測試之前,正確命名測試方法非常重要。 測試方法名稱應包含三個部分。 這些是nameOfMethod(您要測試的單個方法的名稱,例如在測試觸發器時插入/更新/刪除/取消刪除,有關TestPath的信息(例如,如果您要測試聯繫人為空,則為空聯繫人)是靈活的,並且在測試時有效積極/消極的道路。
  • 確保100%的覆蓋率– 儘管標準Salesforce指令要求單元測試覆蓋代碼的75%(減去測試類,對System.debug的調用和測試方法),並且您將無法部署Apex代碼或打包AppExchange應用,但您應該請注意,這只是一個標準,您的目標應該是100%覆蓋率。 測試所有陽性/陰性病例以及存在和不存在的數據。 關於代碼覆蓋率的其他重要提示是:
    • 您應該運行測試以刷新代碼覆蓋率編號,因為更新Apex代碼之前不會重新刷新這些編號,直到重新運行測試為止。
    • 如果自上次測試運行以來組織中已有更新,則存在代碼覆蓋範圍編號不正確的風險。 重新運行測試以獲得正確的估計值。
    • 代碼覆蓋率百分比不包括託管軟件包測試的代碼覆蓋率,唯一的例外是這些測試導致觸發觸發器時。
    • 覆蓋範圍取決於代碼行的總數。 如果添加或刪除代碼行,則會影響百分比。
  • 類和控制器中的測試用例– 在Salesforce開發中,大多數開發人員為每個功能創建單獨的類和控制器文件。 這樣做是為了使編碼更加有條理,更容易,可重用和可移植。 但是,您應該注意,雖然這比較容易,但是效率不高。 如果測試代碼位於原始類和控制器代碼本身中,則將實現可移植性,因為從沙箱遷移到生產環境時,您不會錯過任何測試類。
  • 使用System.assert()– 在Apex中 系統斷言()用於檢查條件。 這是一項重要的功能,因為它使您可以確定該方法是否已按預期執行了特定功能。 您應該在關鍵功能之間使用System.assertEquals()和System.assertNotEquals()不僅可以幫助您確定是否已按預期方式執行了代碼,而且還可以確保在代碼出錯時不會錯誤地寫入數據。
  • 綜合測試 –測試應涵蓋所有內容。 您應該進行功能測試,負載測試,安全測試和部署測試。
  • 單元測試– 您應該進行單元測試,以驗證各個記錄是否產生正確和預期的結果。 儘管使用覆蓋整個代碼的巨大測試似乎是一個好主意,但請注意,生成的結果將更難以調試,而失敗將更難以理解。 單元測試應涵蓋所測試功能的一小部分。
  • 測試大宗案件– 一個好的測試代碼(觸發器,異常或類)可能涉及多達數百條記錄(對於Apex,則為200條)。 您應該利用這一優勢,不僅要測試單個記錄,還要測試大宗案件。
  • 正面測試– 測試以確保是否在所有預期排列中都發生了預期行為。 測試應驗證用戶正確填寫了表格,並且他/她沒有超出限制。
  • 陰性測試– 測試否定情況,以確保正確生成錯誤消息。 此類否定案例的示例無法指定負數,也無法添加將來的日期。 負面的測試很重要,因為當事情往南走時正確的處理可能會帶來不同。
  • 自動化測試– 傳統上,Salesforce測試是手動的。 您應該考慮進行自動化測試,因為這可以提供更多優勢。 這些包括:
    • 手動測試使您容易出錯,因為測試是人工而非機器人進行的。 機器人擅長重複性活動,而人則由於無聊,注意力不集中和保持一致性以及偷工減料而犯錯。
    • 手動測試是重複的,公式化的和累人的。 測試團隊最好進行更具探索性的工作。
  • 執行每個代碼邏輯分支– 使用條件邏輯時(當您包含三元運算符時),應執行代碼邏輯的每個分支。
  • 使用無效和有效的輸入來調用方法– 對方法的調用應同時使用無效輸入和有效輸入。
  • 完整測試– 確保測試成功完成-除非出現預期的錯誤,否則它們不應通過任何例外。 處理所有捕獲到的異常-捕獲它們還不夠好。
  • 使用ORDER BY關鍵字– 為確保按期望的順序返回記錄,請使用ORDER BY關鍵字。
  • 不要假設記錄ID是按順序排列的– 避免假設記錄ID按順序排列的常見錯誤。 除非您在同一請求中插入了多條記錄,否則這些ID並不是按升序排列的。
  • 調用Test.startTest()和Test.stopTest()– 當您運行Apex單元測試時,您將獲得超過75%的代碼覆蓋率,這在Salesforce中是必需的。 您應該在斷言之前調用stopTest來強制可能仍在運行的異步代碼完成。 運行新查詢以獲取最終結果,因為其他代碼可能會更改數據。 usingTest.startTest()和Test.stopTest()可確保您在調速器限制內對測試進行沙箱測試。 這樣,您使用的設置代碼將不會產生干擾,並且會給您錯誤的否定或肯定的限制。 Test.stopTest()還確保@future調用將完成以進行測試。
  • 可讀性– 可讀性在單元測試中非常重要。 測試名稱應包括要採取的具體措施和預期結果。 該方法應具有描述性且簡短。 該方法應可在不同測試中重複使用。
  • 在startTest之前構建大型測試數據集– 由於您的測試將在不同的沙盒和生產環境中運行,因此在調用startTest之前應先構建大型測試數據集,以確保測試具有完整的執行限制。 默認, Salesforce Github 運行與生產數據隔離的測試。 當您需要諸如Profile之類的系統數據時,請進行查詢以獲取適合該特定環境的信息。
  • 生成您自己的測試數據– 您使用的測試數據應在測試中生成。 您可以使用@testSetup批註和TestUtils類生成此數據,不僅可以確保您擁有正確的數據,還可以確保所有測試都在開發人員沙箱上運行,而無需數據。
  • 避免無操作的AKA空操作– 許多測試人員使用無操作AKA空操作。 這些是無用的代碼,什麼也不做。 由於它們已經存在於您的代碼庫中,因此它們會增加您的覆蓋率。
  • 並行測試執行– 從Salesforce用戶界面或開發者控制台啟動測試時,測試將並行運行。 這是一項重要功能,因為它可以加快測試運行時間。 但是,您應該注意,這可能會導致數據爭用問題,如果您懷疑可能會發生這種情況,請關閉並行執行。 導致經常出現UNABLE_TO_LOCK_ROW錯誤的數據爭用問題的最常見原因是:
    • 當測試旨在同時更新相同記錄時。 當測試不創建自己的數據時,通常會更新相同的記錄。
    • 當並行運行的測試出現死鎖時,它們會嘗試創建具有匹配索引字段值的記錄。 當2個正在運行的測試排隊回滾數據時,將發生死鎖(當2個測試輸入記錄具有相同的唯一索引字段值且順序不同時,將發生死鎖)。
    • 要關閉並行測試執行,請轉到“設置”,進入“ Apex測試”,進入“ Apex測試執行選項”對話框,選擇“禁用並行Apex測試”,然後單擊“確定”。

禁用並行Apex測試

聘請專業人士,因為他將擁有完成良好測試所必需的經驗和培訓,這也使您放心。 聘請專業人士可以讓您專注於自己的核心業務。 由於您不需要內部團隊來完成工作,因此還可以節省金錢。

你覺得呢?

本網站使用Akismet來減少垃圾郵件。 了解您的評論如何處理.