Автоматизировать ввод OTP в сквозных тестах кажется простой задачей: взять код из письма и вставить в поле. На практике всё упирается в детали — письмо приходит не сразу, старые сообщения мешают, а ограничение на повторную отправку не даёт просто повторить попытку. Разберём, как построить устойчивую проверку и где всё-таки нельзя обойтись без человека.
Откуда тест берёт код
Сквозной тест проверяет систему снаружи, как обычный пользователь, поэтому код подтверждения он должен добыть так же — из письма. Значит, у теста есть собственный адрес, который он указывает при регистрации или при входе, и доступ к содержимому пришедших туда сообщений.
Способы получить письмо различаются, но суть одна: тест обращается к хранилищу входящих и ищет сообщение, которое относится к его сценарию. Дальше из текста извлекается код — обычно это короткая последовательность цифр, — и вставляется в форму.
Ключевой вопрос здесь не «как прочитать письмо», а «как убедиться, что прочитано именно своё». Если письма приходят в общий ящик, эта уверенность исчезает, и появляются плавающие падения, которые очень трудно объяснить.
Почему письмо приходит не тогда, когда ждёшь
Доставка почты асинхронна. Между нажатием кнопки и появлением письма проходит время, и оно не фиксировано: обычно это секунды, но при нагрузке или задержке на стороне почтовой службы срок растёт. Кроме того, одна и та же доставка может повториться — повторная передача предусмотрена на случай сбоя, и это нормально.
Отсюда следуют три вывода, которые определяют всю конструкцию теста.
Первый: ждать нужно событие, а не время. Пауза наугад делает тест либо медленным, либо ненадёжным.
Второй: нужно уметь распознавать повтор. Если пришло два одинаковых письма, тест должен взять любое и не сломаться.
Третий: у ожидания должен быть предел. Бесконечное ожидание превращает зависшую сборку в загадку, тогда как явная ошибка «код не пришёл за отведённое время» сразу указывает на проблему.
Какие помехи встречаются чаще всего
| Помеха | Как выглядит | Что помогает |
|---|---|---|
| Старое письмо | код уже не действует, форма отклоняет ввод | брать письмо, пришедшее после начала шага |
| Два письма подряд | тест берёт первое, а верно второе | учитывать время и порядок сообщений |
| Чужое письмо | код относится к другому сценарию | отдельный адрес на каждый сценарий |
| Письмо на другом языке | шаблон разбора не находит цифры | искать по структуре, а не по формулировке |
| Письмо с несколькими числами | извлекается не тот номер | ограничивать поиск областью письма |
| Ограничение на отправку | повторный код не приходит | понимать, что переотправка не бесконечна |
Отдельно стоит сказать про последнюю строку. Ограничение на повторную отправку — часть работы сервиса, а не препятствие. Если тест упирается в него, это значит, что тест слишком часто просит новый код: вероятно, он не дождался предыдущего письма и запросил ещё одно. Лечится это не отключением ограничения, а правильным ожиданием.
Почему старые письма особенно мешают?
Потому что они выглядят точно так же, как новые. Код из прошлого прогона имеет тот же формат, письмо пришло с того же адреса и с той же темой. Разница только во времени и в самом значении, а форма принимает лишь один из них.
Если тест берёт «последнее письмо», он будет прав до первого параллельного запуска или до первого повторного прогона на том же адресе. Однажды он возьмёт устаревший код, форма ответит отказом, и разбираться в этом придётся долго — потому что в отчёте будет видно только неверное значение.
Надёжное решение — привязка к границе. Перед шагом, который вызывает письмо, тест фиксирует текущее состояние хранилища, а после ищет только то, что появилось позже этой отметки. В сочетании с отдельным адресом это убирает почти все помехи.
Что важно разработчику: разбор, ожидание и пределы
Первое — выбирайте письмо по признакам, а не по порядку. Получатель, тема, время появления — этих трёх признаков обычно достаточно, чтобы однозначно указать на нужное сообщение. «Самое свежее» — самый слабый из возможных признаков.
Второе — разбирайте текст терпимо к изменениям. Письмо может прийти в виде простого текста или разметки, с переносами, с дополнительными числами в подписи. Если шаблон поиска жёстко привязан к одной формулировке, любая правка текста письма сломает тест. Полезно искать код в пределах смысловой части письма и проверять, что он действительно похож на код, а не является, например, номером заказа.
Третье — используйте разумные пределы ожидания. Ориентир простой: тест должен успевать на нормальной доставке и завершаться ошибкой на отсутствующей. Если для этого приходится ждать слишком долго, значит, проверяется не то, что нужно.
Четвёртое — не отключайте ограничение на повторную отправку ради теста. Оно защищает сервис и от чужого давления, и от собственных ошибок. Если тест без него не проходит, проблема в тесте, а не в ограничении.
Пятое — оставляйте след. Когда код не пришёл или не подошёл, самое полезное — сохранить адрес, время запроса и текст найденного письма. Без этого разбор превращается в догадки, потому что воспроизвести конкретную доставку почти невозможно.
Шестое — решите, где нужен человек. Полностью машинная проверка уместна для кода из письма в тестовом окружении. Но если сценарий проверяет реальные ограничения — например, поведение при исчерпанном лимите или при заблокированном адресе, — часть шагов придётся проверять вручную: автоматизация там либо невозможна, либо создаёт ложную уверенность.
И последнее: адрес для таких проверок остаётся тестовым. Код, полученный на временный ящик, пригоден только для проверки системы, а не для доступа к чужому аккаунту или подтверждения чьей-то личности.
Как не сломать проверку самому?
Есть несколько решений, которые выглядят как ускорение теста, но на деле убирают саму проверку.
Первое — заранее известный код. Если сервис умеет в тестовом окружении выдавать одно и то же значение, тест перестаёт проверять главное: что код действительно доходит до человека по почте. Такой режим полезен для отладки, но как основная проверка он бесполезен.
Второе — отключение ограничения на повторную отправку. Тогда тест, не дождавшийся письма, просто запрашивает новое, и проблема с ожиданием прячется вместо того, чтобы быть найденной.
Третье — проверка только длины кода. Формально значение непустое, но совпадает ли оно с тем, что ждёт система, никто не проверяет. Ошибка в генерации кода при этом останется незамеченной.
Четвёртое — игнорирование адреса. Если тест не проверяет, на какой адрес ушло письмо, он не заметит ошибку, при которой код приходит другому пользователю. Это редкий, но самый неприятный класс дефектов, потому что он касается чужих данных.
Что делать дальше
Посмотрите на свой тест и ответьте на один вопрос: как он выбирает письмо? Если ответ «берёт последнее», замените это на привязку по времени и получателю — это самое выгодное изменение из возможных. Получите адрес через временную почту, прогоните сценарий вручную и убедитесь, что код находится с первого раза. Как проверять саму отправку, разбирает материал о перехвате писем в тестах, а полный набор случаев для формы подтверждения есть в статье о проверке подтверждения адреса.