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