Ненадійна версія тесту електронної пошти коротка: створити адресу, зачекати п'ять секунд, прочитати перше повідомлення і сподіватися, що воно належить цьому запуску.
Надійна версія все ще проста, але розглядає доставку як асинхронну. Вона створює унікальну адресу, фіксує час старту, опитує протягом дедлайну, підбирає потрібне повідомлення, перевіряє дію продукту та надає достатньо контексту, коли щось не вдається.
Тримайте API‑ключ поза URL
Надсилайте ключ GPTMail у заголовку X-API-Key. Не розміщуйте його у параметрах запиту ?api_key=. URL‑адреси регулярно зберігаються в історії браузера, журналах доступу, системах моніторингу та даних реферера.
X-API-Key: YOUR_API_KEYЗберігайте ключ у менеджері секретів вашого CI та маскуйте його в журналах. Публічний щоденний ключ зручний для досліджень; контрольовані автоматизовані набори тестів мають використовувати ключ, квоту та використання якого ви можете відстежувати.
Поточні кінцеві точки та приклади відповідей підтримуються на сторінці документації GPTMail API.
Одна адреса на запуск
Створюйте нову адресу для кожного незалежно виконуваного тесту. Не базуйте правильність на скриньці, спільній для всього набору тестів.
Записуйте адресу, ідентифікатор сценарію, середовище та час старту тесту. Ці значення дозволяють відхилити застарілі повідомлення та діагностувати колізії без журналювання секретів повідомлень.
Опитування до дедлайну, а не фіксована пауза
Час доставки електронної пошти варіюється. Фіксована пауза в п'ять секунд марна, коли доставка швидка, і ненадійна, коли вона повільна.
Використовуйте обмежений цикл:
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‑завдання.
Точний збіг
«First message in the inbox» не є корисним селектором. Збігайте кілька сигналів:
- отримувач дорівнює адресі, створеній для цього запуску;
- час створення пізніше часу тригеру;
- відправник належить очікуваному сервісу;
- тема або тип повідомлення відповідає потоку;
- ідентифікатор повідомлення ще не був використаний.
Коли відправник може видавати кілька кодів, оберіть найновіше відповідне повідомлення. Збережіть його ID у виводі тесту, щоб повторні спроби випадково не використали його знову.
Читати лише після збігу у списку
Перелік скриньки має бути недорогим кроком виявлення. Завантажуйте повне повідомлення лише для обраного кандидата. Це зменшує непотрібну роботу і уникає парсингу нерелевантних рекламних листів.
Перевіряйте бізнес‑результат, а не лише наявність шестизначного рядка. Надішліть код або відкрийте очікуване посилання, а потім переконайтеся, що обліковий запис досяг правильного стану.
Обробляйте обмеження швидкості як сигнал
Якщо API повертає відповідь про квоту або обмеження швидкості, зупиніть поточну спробу і виведіть інформацію про скидання. Агресивні повтори перетворюють чіткий сигнал про пропускну здатність у шум і можуть затримати інші тести.
Обмежте паралельність у тестовому раннері, особливо коли набір створює багато адрес одночасно. Малий пул воркерів легше налагоджувати, ніж сотні одночасних циклів опитування.
Прибирання без приховування помилок
Прибирання має виконуватись після збору доказів. При успіху видаліть повідомлення або дозвольте короткостроковому зберіганню їх обробити. При невдачі збережіть адресу та ID повідомлення у захищених артефактах CI достатньо довго для розслідування, а потім видаліть їх.
Ніколи не виводьте коди підтвердження, приватні посилання чи повні HTML‑тіла у публічні журнали збірки.
Робіть повтори ідемпотентними
Повторіть тест як новий запуск з новою адресою. Не припускайте, що повторення того ж запиту до того ж облікового запису та скриньки починається з чистого стану. Відправник може анулювати старі коди, обмежувати повторні запити або відхилити дублікати запрошень.
Якщо мережевий запит завершується тайм‑аутом, розрізняйте «не отримано відповіді» і «операція не відбулася». Перевірте спостережуваний стан перед виконанням руйнівного повтору.
Повідомляйте точку збою
Корисна автоматизована помилка ідентифікує один із цих етапів:
- генерація адреси не вдалася;
- дія продукту не вдалася до постановки електронного листа в чергу;
- не надійшло відповідне повідомлення до дедлайну;
- повідомлення надійшло, але вміст не відповідає;
- дія підтвердження не вдалася;
- прибирання не вдалося.
Таке класифікування перетворює випадкове «тест електронної пошти не пройшов» на завдання, яким може займатися команда.
Для більшого тестового матричного набору читайте Справжній план тестування електронної пошти. Для діагностики доставки використовуйте Верифікаційний лист не надходить: знайти поломаний крок.