E2E-тестування email-потоків: як обійтися без платних disposable-сервісів

Чому зовнішні disposable-сервіси шкодять автотестам

Тестування користувацьких сценаріїв, що включають одноразові паролі (OTP), підтвердження реєстрації або магічні посилання, завжди створює складнощі в автоматизації. Браузерні фреймворки, як-от Playwright чи Cypress, чудово заповнюють форми, але код підтвердження потрапляє в поштову скриньку, недоступну напряму з DOM.

Класичне рішення — підключення спеціалізованих API для одноразових скриньок. Проте в реальних проєктах воно швидко породжує проблеми:

• Зайва залежність: ще один зовнішній вендор, ключ у CI/CD та потенційна точка відмови. Падіння стороннього API призводить до хибних «червоних» білдів.
• Непередбачувані затримки: доставка повідомлення через сторонні сервіси може тривати від кількох секунд до хвилини, змушуючи роздувати таймаути.
• Ціна: навіть для кількох сотень тестових листів на тиждень доводиться оплачувати окремий тарифний план.

На практиці будь-який бізнес уже має власні поштові сервери або корпоративну пошту з підтримкою IMAP/SMTP. Цього повністю достатньо для надійного тестування.

Магія сабадресації: одна скринька для сотень тестів

Головний виклик E2E-тестів — ізоляція: кожен запуск реєстрації вимагає унікальної email-адреси. Використовувати звичайний статичний акаунт не можна, оскільки бекенд відхилить повторну реєстрацію.

Рішення полягає у використанні сабадресації (sub-addressing або plus-addressing). Більшість сучасних поштових серверів підтримують формат адреси base+tag@domain.com. Усі листи надходять в основну скриньку base@domain.com, але для вашого додатку це абсолютно унікальний користувач.

Тестовий фреймворк генерує випадковий тег (наприклад, e2e-9x7b2a), формує email, відправляє форму реєстрації, а потім звертається до власного поштового сервера через протокол IMAP.

Підводні камені реалізації: стан повідомлень

При написанні легкого клієнта на базі IMAP важливо врахувати нюанс, який часто спричиняє так звані «флакі» тести. Якщо сценарій перевіряє вхід, вихід і повторний запит коду, у скриньці опиняться два листи з однаковим тегом.

Щоб уникнути помилок верифікації:

• Фільтруйте за прапорцем: запитуйте лише непрочитані листи (seen: false).
• Сортуйте за UID: завжди беріть найновіше повідомлення за ідентифікатором, а не перше зі списку.
• Змінюйте статус: одразу після прочитання позначайте повідомлення прапорцем \Seen.

Оптимізація та стабільність інфраструктури

Щоб тестування пошти працювало швидко та безвідмовно, варто дотримуватися трьох технічних правил:

1. Пул з'єднань IMAP

Поштові сервери (наприклад, Dovecot) обмежують кількість одночасних з'єднань від одного користувача. Створюйте одне постійне з'єднання на кожен worker-процес у тест-раннері, а не відкривайте новий сокет для кожної перевірки.

2. Перевірка папки «Спам»

Якщо лист не надходить у встановлений таймаут, обов'язково перевіряйте директорію Junk перед тим, як завершити тест помилкою. Це допоможе вчасно помітити проблеми з DKIM або SPF тестового середовища.

3. Регулярне очищення

Видаляйте тестові повідомлення після завершення сценаріїв або налаштуйте автоматичне видалення старих листів за розкладом. Навіть без лімітів на розмір сховища велика кількість листів в INBOX уповільнює пошукові запити IMAP.

Відмова від сторонніх сервісів на користь власного IMAP скорочує затримки доставки до менш ніж однієї секунди, ліквідує зайві витрати та робить пайплайн розробки цілком автономним.