Автоматизированному тестированию электронной почты требуется больше, чем адрес почтового ящика. Ему нужен контракт, описывающий, какое сообщение относится к запуску теста, сколько времени ждать и какие доказательства сохранять, если тест завершится неудачей.
Создавайте для каждого запуска запись корреляции
Сохраняйте идентификатор тестового запуска, синтетического получателя, время срабатывания и ожидаемое назначение сообщения. Если ваше приложение это позволяет, включите в тестовое сообщение маркер корреляции, не содержащий конфиденциальных данных. Сопоставляйте сообщения не только по теме: иначе старое сообщение с той же темой может сделать сбойный запуск выглядящим успешным.
Ожидайте в рамках явно заданного бюджета
создать тестовый контекст
запустить действие приложения
пока не истек срок теста:
читать сообщения через документированный API провайдера
принимать только сообщение, соответствующее этому запуску
при отсутствии совпадения ждать с ограниченной задержкой
сообщить о совпадении, тайм-ауте или ошибке провайдераЭто псевдокод, а не пример CleanTempMail API. Используйте актуальную документацию API для аутентификации, эндпоинтов и лимитов запросов. Соблюдайте инструкции по повторным попыткам и отменяйте оставшуюся работу по завершении задания.
Проверяйте поведение после получения
В контролируемой вами тестовой среде убедитесь, что действие верификации приводит к ожидаемому состоянию аккаунта. Само по себе получение сообщения не доказывает, что его ссылка работает. Не допускайте попадания токенов аутентификации и текстов сообщений в обычный вывод CI.
Сделайте сбои диагностируемыми
Различайте сбой отправки со стороны приложения, отсутствие подходящего сообщения до истечения срока, недоступность провайдера и сбой проверки утверждений. Сохраняйте обезличенные метки времени и идентификаторы, а затем удаляйте синтетические аккаунты и почтовые артефакты в соответствии с политикой хранения тестовых данных вашей команды.