無論您是剛開始使用、目前維護應用程式，還是在現有整合中加入新功能，測試都是建立成功 Google Ads API 整合的重要步驟。本指南提供測試 Google Ads API 整合的幾個最佳做法。
測試帳戶
測試帳戶可用於開發。雖然測試帳戶無法測試所有功能，但這仍很適合用來驗證應用程式程式碼和設定是否正常運作。
開發環境帳戶
當測試帳戶限制導致您無法測試整合中的部分功能時，您可以改用正式版帳戶進行開發。開發環境帳戶和測試帳戶有以下不同：
- 放送使用者可以看到的廣告
- 需要有效的網址
- 必須遵守廣告政策
由於實際執行帳戶會放送廣告，因此產生的指標可讓您測試成效報表，並解鎖 Google Ads API 的所有其他功能。
不過，使用這類 API 進行開發時必須格外小心。建議您採取下列措施：
- 請務必只將基於開發目的需要這項權限的使用者授予存取權。
- 設定固定的低每日帳戶預算。
- 只有在測試帳戶無法使用時，才將實際執行帳戶用於開發。
測試憑證
為了盡可能降低嘗試修改開發帳戶時意外修改實際執行帳戶的風險，建議您保留一組與正式版應用程式憑證不同的測試憑證。
另外，我們也建議您基於開發作業需求建立個別的更新權杖。
如果使用者授權應用程式代表他們存取 Google Ads API，系統就會產生更新權杖，因此每個更新權杖的存取權都與授權使用者相同。如果用於存取開發帳戶的所有更新憑證，與「沒有」存取權的使用者相關聯 (包括管理實際執行帳戶的管理員帳戶)，就會減少意外使用測試更新憑證來修改實際執行帳戶的風險。
存取權取決於使用的更新權杖，因此您不必建立測試更新權杖以外的測試憑證。只要更新權杖各不相同，開發人員權杖、用戶端 ID 和用戶端密鑰即可安全存取測試帳戶。
提出驗證要求
如果您只需要測試要求是否有效 (例如，確認要求的結構正確無誤且未違反政策)，可以使用 validate_only 欄位 (適用於 GoogleAdsService.SearchStream 和 GoogleAdsService.Search 要求)，以及大部分的變更要求。請參閱參考說明文件，確認特定方法是否支援這個欄位。
REST API
如果是臨時測試，例如驗證要求是否會產生預期輸出內容，使用 REST API 通常是最簡單的選項。請參閱 REST 範例，瞭解如何使用 cURL 向 REST API 發出要求。