Ненадёжная версия теста электронной почты коротка: создать адрес, подождать пять секунд, прочитать первое сообщение и надеяться, что оно относится к текущему запуску.
Надёжная версия всё ещё проста, но рассматривает доставку как асинхронную. Она создаёт уникальный адрес, фиксирует время начала, опрашивает в пределах дедлайна, сопоставляет нужное сообщение, проверяет действие продукта и предоставляет достаточно контекста, когда что‑то происходит не так.
Держите API‑ключ вне URL
Отправляйте ключ GPTMail в заголовке X-API-Key. Не помещайте его в параметры запроса ?api_key=. URL‑адреса регулярно сохраняются в истории браузера, журналах доступа, системах мониторинга и данных рефереров.
X-API-Key: YOUR_API_KEYХраните ключ в менеджере секретов CI и маскируйте его в логах. Публичный ежедневный ключ удобен для экспериментов; контролируемые автоматизированные наборы тестов должны использовать ключ, квоту и использование которого вы можете отслеживать.
Текущие конечные точки и примеры ответов поддерживаются на странице документации API GPTMail.
Один адрес на запуск
Создавайте новый адрес для каждого независимо исполняемого теста. Не определяйте корректность, полагаясь на ящик, общий для всей тестовой серии.
Записывайте адрес, идентификатор сценария, окружение и время начала теста. Эти значения позволяют отклонять устаревшие сообщения и диагностировать коллизии без логирования секретов сообщений.
Опрос до дедлайна, а не фиксированная пауза
Время доставки электронной почты варьируется. Фиксированная пауза в пять секунд неэффективна, когда доставка быстрая, и ненадёжна, когда она медленная.
Используйте ограниченный цикл:
deadline = now + 90 seconds
delay = 2 seconds
while now < deadline:
messages = list inbox
candidate = newest message matching sender, subject, and start time
if candidate exists:
read candidate and continue the product test
wait delay with a small random jitter
delay = min(delay * 1.5, 10 seconds)Дедлайн является частью контракта теста. Процесс сброса пароля может требовать другого лимита, чем предварительный просмотр массовой рассылки. Делайте лимит явным, чтобы медленная зависимость не растягивала бесшумно всю задачу CI.
Точное сопоставление
«Первое сообщение в ящике» не является полезным селектором. Сопоставляйте несколько сигналов:
- получатель совпадает с адресом, созданным для этого запуска;
- время создания позже времени триггера;
- отправитель принадлежит ожидаемому сервису;
- тема или тип сообщения соответствуют процессу;
- ID сообщения ещё не был использован.
Если отправитель может выдать несколько кодов, выберите самое новое подходящее сообщение. Сохраните его ID в выводе теста, чтобы повторные попытки случайно не использовали его повторно.
Чтение только после совпадения в списке
Получение списка сообщений должно быть дешёвым шагом обнаружения. Полное сообщение запрашивайте только для выбранного кандидата. Это уменьшает лишнюю работу и избегает парсинга нерелевантных рекламных писем.
Проверяйте бизнес‑результат, а не только наличие шестизначной строки. Отправьте код или откройте ожидаемую ссылку, затем убедитесь, что аккаунт переходит в корректное состояние.
Обрабатывайте ограничения скорости как сигнал
Если API возвращает ответ о квоте или ограничении скорости, остановите текущую попытку и отобразите информацию о сбросе. Агрессивные повторные попытки превращают ясный сигнал о нагрузке в шум и могут задержать несвязанные тесты.
Ограничьте параллелизм в тестовом раннере, особенно когда набор создаёт множество адресов одновременно. Небольшой пул воркеров проще отлаживать, чем сотни одновременных циклов опроса.
Очистка без скрытия ошибок
Очистка должна выполняться после захвата доказательств. При успехе удаляйте сообщения или позволяйте им исчезнуть по короткому сроку хранения. При ошибке сохраняйте адрес и ID сообщения в защищённых артефактах CI достаточно долго для расследования, а затем удаляйте их.
Никогда не выводите коды подтверждения, приватные ссылки или полные HTML‑тела в публичные логи сборки.
Делайте повторные попытки идемпотентными
Повторяйте тест как новый запуск с новым адресом. Не полагайтесь на то, что повтор того же запроса к тому же аккаунту и ящику начинается с чистого состояния. Отправитель может аннулировать старые коды, ограничивать частоту повторных запросов или отклонять дублирующие приглашения.
Если сетевой запрос истекает, различайте «ответ не получен» и «операция не произошла». Проверьте наблюдаемое состояние перед выполнением разрушительной повторной попытки.
Сообщайте точку сбоя
Полезный сбой автоматизации указывает на одну из следующих стадий:
- не удалось сгенерировать адрес;
- действие продукта не удалось до постановки письма в очередь;
- не пришло подходящее сообщение до дедлайна;
- сообщение пришло, но его содержимое не совпало;
- действие проверки не удалось;
- не удалось выполнить очистку.
Эта классификация превращает случайный «тест почты не прошёл» в задачу, которой может владеть команда.
Для более широкой матрицы тестов читайте Настоящий план тестирования электронной почты. Для диагностики доставки используйте Письмо с подтверждением не приходит: найдите сломанный шаг.