Тестирование промокодов StoreKit нужно разделить на два контура: сначала проверить покупочную логику в локальной конфигурации Xcode, затем провести погашение кода, созданного для Sandbox, с Sandbox Apple Account. Локальный успешный сценарий подтверждает обработку тестовой покупки, но не доказывает, что фактический маршрут погашения промокода работает.
Материал подойдёт независимым разработчикам, которые добавляют в iOS-приложение погашение промокода для автоматически продлеваемой подписки. Он также поможет разработчикам, уже настроившим предложение в App Store Connect, и небольшим командам, которым нужно сверить обработку транзакций и выдачу прав.
Сначала распределите проверки по ролям и средам
Одна и та же надпись «покупка прошла» может относиться к разным доказательствам. Локальная конфигурация StoreKit позволяет отлаживать поведение приложения на тестовых данных, а Sandbox нужен для проверки пути, связанного с промокодом и тестовой учётной записью. Результаты следует записывать раздельно: иначе команда может принять проверенную покупочную логику за подтверждённое погашение кода.
| Ответственный | Что он принимает | Чем подтверждать | Чего этот результат не доказывает |
|---|---|---|---|
| Разработчик покупочной логики | Отображение подписок, результат тестовой покупки, реакцию приложения на транзакцию | StoreKit Testing и наблюдаемое состояние приложения | Что тестовый промокод погашается в Sandbox |
| Ответственный за App Store Connect | Настройку предложения и подготовку тестового кода | Настройки подписки и сведения о созданном предложении | Что приложение правильно обрабатывает полученную транзакцию |
| Разработчик клиентского интерфейса | Системный маршрут погашения и, если реализован, маршрут внутри приложения | Действия на тестовом устройстве и результат StoreKit | Что сервер выдал соответствующие права |
| Ответственный за подписки и сервер | Обновление состояния прав и получение событий | Транзакция, состояние пользователя и записи тестового контура | Что весь процесс проверен только потому, что сборка завершилась без ошибок |
В документации Apple локальная настройка описана как StoreKit Testing в Xcode с конфигурацией покупок проекта. Для такого теста приложению не требуется проходить тот же путь, что при проверке погашения предложения в Sandbox. Поэтому фиксируйте среду рядом с каждым результатом, а не объединяйте локальные и Sandbox-логи в один статус. См. руководство Apple по настройке StoreKit Testing в Xcode.
| Проверяемая возможность | StoreKit Testing в Xcode | Sandbox-проверка промокода |
|---|---|---|
| Проверить реакцию приложения на тестовую покупку | Да, в пределах выбранной конфигурации и сценария | Можно дополнительно сверить обработку результата Sandbox |
| Проверить создание предложения и тестового кода | Нет, локальный файл конфигурации не заменяет настройку App Store Connect | Да, тестовый сценарий начинается с подготовленного предложения и кода |
| Проверить системное погашение | Не считать локальную покупку доказательством работы системного маршрута | Да, используйте Sandbox Apple Account и тестовое устройство |
| Проверить внутреннюю кнопку погашения | Только ту часть, которую действительно воспроизводит локальный сценарий | Да, если приложение реализует этот маршрут, проверьте его отдельно |
| Подтвердить выдачу серверных прав | Можно проверить клиентскую реакцию в подходящем тестовом сценарии | Сверьте транзакцию, состояние прав и Sandbox-события |
Разработчику, отвечающему за покупочную логику
Настройте StoreKit Configuration File в проекте и свяжите его со схемой запуска, чтобы приложение получало тестовый каталог покупок для локальной проверки. Затем пройдите путь от загрузки предложения до изменения интерфейса после покупки. Файл конфигурации удобен для повторяемой отладки: разработчик может проверять логику приложения, не выдавая локальный сценарий за реальное погашение промокода.
Проверяйте не только экран успешной покупки. Убедитесь, что приложение получает наблюдаемый результат StoreKit, обрабатывает его и переводит доступ к функциям в ожидаемое состояние. Если интерфейс показывает активную подписку на основании собственного временного флага, а не обработанного результата, локальная проверка должна выявить это расхождение до Sandbox-приёмки.
В локальном сценарии записывайте, какой именно файл StoreKit Configuration использовался и какое состояние покупки наблюдалось. Без этой привязки одинаковый скриншот может относиться к разным конфигурациям и не объяснять, что именно было проверено.
Ответственному за App Store Connect
До передачи кода тестировщику проверьте, что предложение относится к нужной подписке и подготовлено для требуемого тестового сценария. Создание предложения в App Store Connect — отдельная часть процесса: конфигурация Xcode не создаёт промокод и не подтверждает настройки предложения. Apple описывает необходимые действия в справке по настройке кодов предложений для подписок.
Отдельно обозначьте, какой код предназначен для проверки, а какой — для покупателей. Тестовые данные не следует копировать в таблицы маркетинговой кампании, инструкции поддержки или материалы публикации: тогда команда не сможет надёжно понять, какой код и в какой среде использовался. Для Sandbox создайте соответствующую тестовую учётную запись по инструкции Apple по созданию Sandbox Apple Account.
Не считайте подготовку учётной записи доказательством успешного теста. Это лишь условие для работы тестового контура; результатом остаются наблюдаемое погашение, транзакция и корректное состояние подписки в приложении.
Разработчику, проверяющему погашение на устройстве
Если проверяется системный маршрут, начните с системного интерфейса погашения на устройстве и войдите в тестовую среду согласно сценарию Apple. После завершения действия зафиксируйте, что произошло дальше: появился ли результат в приложении, была ли обработана транзакция и изменилось ли состояние доступа. Для сценариев покупок вне приложения Apple отдельно описывает тестирование покупок, инициированных за пределами приложения.
Если приложение предлагает вводить код или запускать погашение из собственного интерфейса, проверяйте этот путь отдельно от системного. Сначала подтвердите, что приложение действительно реализует подходящую поддержку StoreKit, затем проверьте действие кнопки, открытие системного интерфейса и последующую обработку результата. Документ Apple о поддержке кодов предложений внутри приложения следует использовать для сверки реализованного API и требований, а не как подтверждение того, что конкретный интерфейс уже работает.
Если тестировщик видит сообщение о принятом коде, но приложение не меняет права пользователя, сценарий ещё не пройден. Фиксируйте отдельно действие погашения, результат транзакции и состояние доступа — это три разные точки диагностики.
Команде, отвечающей за подписку и серверные права
После погашения сопоставьте результат на клиенте с объектом транзакции, который приложение фактически обработало. В документации Apple описан объект StoreKit Transaction; используйте его как основание для проверки сведений о покупке и состояния подписки в вашем процессе обработки. Не делайте вывод о доступе только по сообщению интерфейса: приложение могло показать временный экран до завершения обработки или не обновить локальное состояние после получения результата.
Если сервер принимает App Store Server Notifications, проследите, что тестовые события учитываются в тестовом контуре и не смешиваются с производственными записями. Apple публикует инструкцию по включению App Store Server Notifications; конкретные события и поля сверяйте с действующей документацией и реализацией проекта. Сопоставьте запись события с пользователем, состоянием подписки и ответом приложения, не выдавая Sandbox-уведомление за производственную покупку.
Для базовой проверки Sandbox используйте официальный материал Apple о тестировании встроенных покупок в Sandbox. Если в проекте есть серверная валидация или собственная модель прав, приёмка должна включать и её: Sandbox-погашение само по себе не гарантирует, что сервер обновил нужную запись и приложение отобразило актуальный доступ.
FAQ: уточнения перед приёмкой
Можно ли ограничиться локальной конфигурацией Xcode?
Нет, если цель — принять именно погашение промокода. StoreKit Testing подходит для логики покупки, транзакций и реакции интерфейса в локальном сценарии. Но он не подтверждает, что предложение настроено в App Store Connect и что код проходит Sandbox-путь. Поэтому локальную проверку используйте как первый этап, а результат погашения подтверждайте отдельно тестовой учётной записью.
Где подготовить Sandbox-код и как начать его проверку?
Подготовьте предложение для подписки в App Store Connect и создайте Sandbox Apple Account по официальному процессу Apple. Затем проверьте маршрут погашения на тестовом устройстве. Системный интерфейс и интерфейс приложения — самостоятельные варианты проверки: если приложение не поддерживает собственный маршрут, не включайте его в критерии прохождения.
Как принять ввод кода внутри приложения?
Сначала подтвердите, что соответствующий StoreKit-процесс реализован в приложении; затем выполните проверку с Sandbox-учётной записью. Запишите, что сделал пользователь, какой интерфейс открылся, была ли получена транзакция и обновились ли права. Если проверены только поле ввода или появление системного окна, результат относится к частичной проверке, а не к полному прохождению сценария.
Что считать доказательством выдачи прав подписчика?
Нужны согласованные данные: обработанная транзакция, ожидаемое состояние доступа в приложении и, если используется сервер, соответствующая запись серверного контура. Для настроенных уведомлений сопоставьте Sandbox-событие с тестовыми данными. Сообщение «код принят» без подтверждения прав недостаточно: оно не показывает, что подписка действительно доступна пользователю после обработки покупки.
Зафиксируйте результат по чек-листу
Соберите свидетельства так, чтобы другой разработчик мог повторить сценарий и понять границы результата.
- [ ] Для локальной проверки записаны схема запуска, файл StoreKit Configuration и тестируемый товар.
- [ ] Отдельно указано, какие действия и состояния проверялись через StoreKit Testing.
- [ ] В App Store Connect найдено нужное предложение для требуемой подписки.
- [ ] Тестовый код отделён от кодов, предназначенных для покупателей.
- [ ] Для Sandbox подготовлена тестовая учётная запись, а тест выполнялся в обозначенной среде.
- [ ] Для системного погашения записан фактический результат на устройстве.
- [ ] Если приложение поддерживает собственный маршрут погашения, он проверен отдельно.
- [ ] Сохранены наблюдаемая транзакция, результат обработки и отображаемое состояние прав.
- [ ] При серверной обработке Sandbox-события сверены с тестовыми, а не производственными записями.
- [ ] В отчёте указано, какие пункты не проверялись и требуют повторного теста.
Статус «пройдено» ставьте только для тех маршрутов, для которых есть подтверждение на каждом нужном уровне. Если локальная покупка работает, но Sandbox-код не погашался, покупочная логика может быть принята, а функция промокодов — нет. Если код погашен, но состояние прав не совпадает с транзакцией, серверную или клиентскую обработку следует считать незавершённой. Отметка «нужно дополнительно проверить» подходит, когда есть только подтверждение открытия интерфейса либо отсутствуют записи сервера, обязательные для проекта.
Удалённый Mac может быть рабочей средой для проекта Xcode, сборки и локальной проверки StoreKit, если разработчику нужен доступ к macOS без отдельного локального компьютера. Однако сама сборка на удалённом Mac не подтверждает Sandbox-погашение: тестовая учётная запись, устройство, системный маршрут и серверная обработка по-прежнему должны быть проверены в условиях, предусмотренных сценарием команды. Для временной работы можно изучить варианты доступа к Mac на RUVCLOUD, а перед выбором — условия заказа удалённого Mac.
Если сейчас тестирование выполняется только локально, его преимущества — быстрый повтор сценария и контроль конфигурации; ограничения — отсутствие доказательства фактического Sandbox-погашения, необходимости отдельно организовать тестовую учётную запись и риска не заметить расхождение между приложением и серверными правами. Для постоянной разработки с уже имеющимся Mac аренда не обязательна, а для проверки функций, требующих конкретного физического устройства или сценария аккаунта, удалённая среда не заменяет такой тест. Но когда команде временно нужен macOS для Xcode и локальных проверок, RUVCLOUD может быть удобнее покупки отдельного Mac исключительно под этот этап. Сначала выберите среду под задачу, а затем отмечайте приёмку промокода только по результатам соответствующего Sandbox-сценария.