# Песочница

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

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

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

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

```bash
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
пока нет. Что именно попадёт в журнал сообщений и как будет выглядеть пометка
тестового платежа, станет понятно при реализации.