Заглушка вместо реального SMS-кода в тесте регистрации проверяет форму, но не сценарий целиком: она не ловит задержку доставки, неожиданный формат кода от конкретного сервиса, обрыв на шаге ввода письма-подтверждения. Прогон со всамделишным кодом — единственный способ убедиться, что регистрационная цепочка живая от первого запроса номера до входа в аккаунт.

Зачем нужен сценарий с настоящим кодом

Мок-код всегда приходит мгновенно и в ожидаемом формате — реальность другая. Оператор может задержать доставку на 20–40 секунд, код может прийти двумя SMS вместо одной, письмо с подтверждением может попасть в очередь модерации на стороне почтового сервиса. Ни один из этих сценариев не воспроизводится заглушкой, а именно они чаще всего ломают продакшен-регистрацию, которую до этого месяцами не трогали.

Второй довод — интеграция целиком. Тест с реальным кодом проверяет не только парсинг SMS, но и связку: запрос номера через API, доставку кода до вашей стороны, извлечение кода из текста, ввод в форму, финализацию активации. Обрыв на любом звене — это баг, который стоит поймать в CI, а не на проде.

Как устроен сквозной прогон

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

Таймаут на ожидание кода закладывается с запасом относительно обычной доставки: если код в норме приходит за 10–15 секунд, таймаут в пайплайне разумно ставить на 60–90 секунд, а не на 15. Повтор запроса кода имеет смысл один раз, после первого истёкшего таймаута — вторая попытка ловит редкую задержку оператора, третья обычно означает реальную проблему в цепочке, а не флуктуацию доставки.

Почему это отдельный редкий прогон, а не часть каждого коммита

Тест с реальным кодом стоит денег на каждый запуск — номер или адрес списывается независимо от результата — и зависит от внешнего сервиса, чья задержка не под вашим контролем. Гонять его на каждый коммит означает платить за каждый пуш в ветку и получать случайные красные сборки не по вине кода, а по вине внешней задержки доставки.

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

Изоляция тестовых данных от боевых

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

Учёт расходов на прогоны

Каждый прогон с реальным кодом — это списание за номер или почтовый адрес плюс время выполнения в пайплайне. Стоит считать стоимость одного полного сценария и умножать на частоту прогонов: раз в сутки — один порядок бюджета, на каждый коммит в активной ветке — совсем другой, кратно выше без пропорционального роста пользы. Разумный ориентир — держать редкие прогоны с реальными кодами достаточно частыми, чтобы ловить регрессии до релиза, но достаточно редкими, чтобы стоимость CI не спорила со стоимостью самого сервиса.

Частые вопросы

Можно ли полностью отказаться от заглушек в пользу реальных кодов?

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

Что делать, если код не пришёл за отведённый таймаут?

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

Как часто запускать прогон с реальными кодами?

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

Как устроен запрос номера и опрос статуса кода на стороне API, разобрано в документации API. Получить номер для первого тестового прогона можно в разделе OTP, а принцип опроса состояния через API — тот же, что применяется при ротации IP по API. Расход на регулярные прогоны удобно отслеживать в истории транзакций.