Песочница

Отлаживать интеграцию на живых учениках — плохо, а отлаживать её негде — ещё хуже. Песочница закрывает этот выбор: побочные эффекты выключаются, а всё остальное работает по-настоящему.

У GetCourse API на пробном тарифе просто недоступно, и отлаживаться приходится на живой школе.

Как включить #

Ключом. Заведите в настройках ключ с префиксом lms_test_ и используйте его вместо боевого:

curl -X GET 'https://school.example.com/api/v1/users' \
  -H 'Authorization: Bearer lms_test_5c1e9d2b74a5f8e0c1d3b5a7f9e2ca8f' \
  -H 'Accept: application/json'

Никакого отдельного адреса, отдельного домена и отдельной настройки — тестовый режим включает сам ключ. Одно место, которое можно забыть переключить, вместо трёх.

Что меняется #

Всё остальное — те же операции, те же права, те же лимиты, те же коды ответа и те же ошибки. В этом смысл: отлаживается тот код, который потом пойдёт в бой, а не его тестовый двойник.

Чего это не заменяет #

Здесь три оговорки, и первая важнее двух остальных.

Это та же установка и те же данные #

Песочница не изолирует данные. Тестовый ключ работает против вашей боевой школы: созданный им пользователь — настоящая строка в вашей базе, выданный доступ — настоящий доступ, изменённый курс — изменённый по-настоящему.

Изолируются побочные эффекты наружу: деньги, сообщения, вебхуки. Всё, что происходит внутри школы, происходит на самом деле.

Практически это значит:

• удаление тестовым ключом удаляет по-настоящему. Права ключа песочницы стоит сужать так же тщательно, как боевого, а лучше — сильнее;
• тестовые данные надо за собой убирать. Через месяц отладки в школе живут сорок человек с почтой вида test+7@…, и они попадают в сегменты и отчёты;
• заводите тестового ученика заранее и работайте с ним, а не с первым попавшимся живым.

Это не отдельный стенд #

Если нужно проверить обновление, миграцию или поведение при пустой базе — нужна вторая установка, а не тестовый ключ. Песочница — про интеграцию, а не про инфраструктуру.

Тестовый режим провайдера — не наш #

Платежи уходят в тестовый режим платёжного провайдера, и что именно он в нём позволяет, решает он. Тестовые карты, сценарии отказа, задержки — всё это в его документации, не в нашей.

Как этим пользоваться #

Порядок, который экономит день отладки:

1. Завести ключ lms_test_ с теми правами, которые нужны интеграции. Не с полными.
2. Завести тестового ученика и тестовый курс — руками, один раз.
3. Подписать вебхуки на тестовый адрес приёмника.
4. Прогнать сценарий целиком: заказ, оплата, выдача доступа, сообщение.
5. Проверить журнал сообщений: они должны быть там с пометкой, а не у ученика.
6. Заменить ключ на боевой и прогнать ещё раз — на себе, а не на клиенте.

Шаг 6 не лишний. Тестовый режим не ловит две вещи: неверный боевой адрес приёмника вебхуков и права боевого ключа, которые вы могли задать иначе.

Как понять, каким ключом вы работаете #

По префиксу — но не глазами, а в коде. Проверка ключ.startsWith('lms_test_') на старте вашей интеграции с явным сообщением в журнал стоит одну строку и однажды покажет, что ночная задача полгода ходила тестовым ключом.

Обратный случай неприятнее: боевой ключ в отладочном окружении. Поэтому в примерах на экране создания ключа подставлен именно тот ключ, который вы только что создали — чтобы не копировать чужой из документации.

Чего здесь ещё нет #

Проверенного поведения. Раздел описывает решение, а не работающий код: API пока нет. Что именно попадёт в журнал сообщений и как будет выглядеть пометка тестового платежа, станет понятно при реализации.