Тестирование — важный шаг на пути к успешной интеграции Google Ads API, независимо от того, начинаете ли вы с нуля, поддерживаете приложение или добавляете новые функции в существующую интеграцию. В этом руководстве представлены некоторые рекомендации по тестированию интеграции Google Ads API.
Тестовые и производственные аккаунты
Для целей разработки доступны тестовые учетные записи . С помощью тестовых учетных записей вы можете убедиться, что код и конфигурация вашего приложения работают должным образом.
Однако не все функции можно протестировать в тестовом аккаунте.
Если ограничения тестовой учетной записи не позволяют вам тестировать некоторые функции вашей интеграции, вы можете использовать производственную учетную запись для разработки. Для вызова производственной учетной записи ваш проект Google Cloud должен иметь как минимум уровень доступа Explorer (Explorer, Basic или Standard). Обратите внимание, что доступ Explorer по-прежнему ограничивает доступ к определенным сервисам, включая выставление счетов ( BillingSetupService и AccountBudgetProposalService ), планирование, создание учетных записей и приглашение пользователей (см. ограничения функций Explorer ), для которых требуется доступ Basic или Standard. Попытка вызова производственной учетной записи из проекта с уровнем доступа Test возвращает AuthorizationError.CLOUD_PROJECT_NOT_APPROVED_FOR_PRODUCTION , начиная с v25 , или AuthorizationError.ACTION_NOT_PERMITTED в v24 и более ранних.
Производственные счета для разработки отличаются от тестовых счетов следующими способами:
- Показывать рекламу, которую могут увидеть пользователи.
- Требуется наличие действительных URL-адресов.
- Необходимо соблюдать рекламные правила.
Поскольку в рабочих аккаунтах размещаются объявления, они генерируют метрики, позволяющие тестировать отчеты о производительности, а также открывают доступ ко всем остальным функциям API Google Ads. Однако использование их в целях разработки требует особой осторожности. Мы рекомендуем принять следующие меры:
- Предоставляйте доступ только тем пользователям, которым он необходим для целей разработки.
- Установите фиксированный, низкий ежедневный бюджет счета.
- Используйте рабочие учетные записи для разработки только в том случае, если тестовые учетные записи использовать невозможно.
Таким образом, для проведения полноценного тестирования вашей интеграции вам, вероятно, понадобятся как тестовые, так и рабочие учетные данные.
Тестовые учетные данные
Чтобы свести к минимуму риск случайного изменения учетных записей в рабочей среде при попытке изменить учетные записи в среде разработки, мы рекомендуем использовать отдельный набор тестовых учетных данных, не связанный с учетными данными вашего рабочего приложения.
Для создания набора тестовых учетных данных выполните следующие шаги:
- Создайте учетную запись электронной почты (например,
api.test@example.com) или служебную учетную запись, которая будет использоваться исключительно в целях тестирования. - Добавьте этого пользователя или сервисный аккаунт в качестве действительного пользователя в аккаунты Google Ads, для которых вы проводите тестирование. Убедитесь, что вы предоставили этому пользователю или сервисному аккаунту соответствующие уровни доступа . Не предоставляйте этому пользователю или сервисному аккаунту доступ к каким-либо рабочим аккаунтам .
- Если вы используете аутентификацию пользователей по протоколу OAuth 2.0, а не по протоколу служебной учетной записи , сгенерируйте токен обновления для вашей тестовой учетной записи пользователя.
- Используйте эти новые учетные данные при тестировании вашего приложения. Идентификатор клиента и секретный ключ клиента можно повторно использовать в целях тестирования, поскольку они не влияют на определение того, к каким аккаунтам Google Ads можно получить доступ. Храните все учетные данные и токены обновления в безопасном месте и никогда не добавляйте их в систему контроля версий.
Проверка запроса
Если вам нужно просто проверить корректность запроса — например, убедиться, что запрос правильно структурирован и не нарушает правила, — вы можете использовать поле validate_only , которое доступно для запросов GoogleAdsService.Search (обратите внимание, что GoogleAdsService.SearchStream не поддерживает validate_only ) и большинства запросов mutate. Обратитесь к справочной документации , чтобы проверить, доступно ли это поле для конкретного метода.
REST API
Для оперативного тестирования, например, для проверки того, что запрос выдает ожидаемый результат, использование REST API часто является самым простым вариантом. Обратитесь к примерам REST , чтобы узнать, как использовать curl для отправки запросов к REST API. Также попробуйте проводить тестирование в REST Explorer .