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