Как тестировать интеграцию и не сорить
Песочницы здесь нет. Есть кое-что лучше: вызов, который проверяет всё и не создаёт ничего.
Начните с сухого прогона
Эндпоинт валидации принимает то же тело, что и создание, применяет ту же схему и те же правила имён и возвращает все проблемы разом, ничего не записывая. Большую часть интеграции можно разрабатывать против него: имена полей, формы блоков, обработку ошибок, весь путь от ответов человека до валидного запроса.
Это же честный первый вызов и в проде. Прогон, который валидирует перед созданием, превращает череду полуотказов в один список и никогда не сжигает адрес на теле, которое всё равно отвергли бы.
- Разрабатывайте против валидации, пока тело не станет правильным, а обработка ошибок — проверенной.
- Потом создайте одну настоящую страницу на одноразовом адресе и прочитайте её обратно в Markdown.
- Проверьте, что claim-ссылка открывается, а страница нормально выглядит на телефоне.
- Удалите страницу, когда закончите. Удаление уносит с собой файлы и статистику.
Что легко забыть проверить
- Занятое имя: ждите конфликт с вариантами и убедитесь, что показываете их, а не выбираете сами.
- Лимит: ждите 429 с retryAfter и убедитесь, что ждёте, а не крутите цикл.
- Повтор: пришлите один и тот же ключ идемпотентности дважды и убедитесь, что получили одну страницу, а не две.
- Плохой адрес картинки: страница всё равно создастся, а сбой придёт в предупреждениях.
Мусор и что с ним происходит
Каждая оставленная тестовая страница держит адрес навсегда, потому что удалённое имя остаётся припаркованным: старые ссылки не должны начать вести на постороннего. Это единственная цена небрежных экспериментов, и платит её следующий, кому это имя было нужно.
Страховка есть: страница, сделанная программой, никем не забранная и ни разу не открытая, снимается с публикации через тридцать дней и удаляется через шестьдесят, а имя освобождается, а не паркуется. Полагайтесь на это для прогонов, о которых забыли, а не для тех, что идут прямо сейчас.