Тестові адреси, які не спричиняють інцидентів
Тестування будь-чого, що надсилає пошту, впирається в те саме питання: яку адресу вписати? Неправильна відповідь дає клас помилок, які нічого не ламають, але за які соромно, — лист із вашого тестового середовища приходить справжній людині.
Спершу вирішіть, чи лист має дійти
Це одне питання вирішує все, і ставити його варто явно, бо відповідь «ні» буває частіше, ніж припускають.
| Що ви тестуєте | Лист має дійти? | Що брати |
|---|---|---|
| Перевірку, зберігання, показ адреси | ні | зарезервований домен — див. нижче |
| Сценарій підтвердження, руками | так | скриньку тут |
| Сценарій підтвердження, автоматично | так, і читати має код | сервіс з API |
| Навантажувальне тестування | ні — і не повинен | зарезервований домен, завжди |
Коли лист не має дійти: зарезервовані імена
Для цього існують два домени, які гарантовано нікому не належать: example.com разом із example.net та example.org, зарезервовані RFC 2606, а також цілий домен верхнього рівня .test.
Адреси на них — правильна відповідь для фікстур, тестових даних і навантажувальних прогонів. Жоден надісланий лист не дійде до людини, бо там нікого немає: за міжнародною домовленістю, а не за випадковим збігом.
test@mycompanytest.com достатньо часто виявляється чиїмось справжнім доменом, а навантажувальний прогін по ньому нічим не відрізняється від атаки. Зарезервовані імена не коштують нічого й прибирають цілу категорію прикрих випадковостей.Коли лист має дійти, і ви дивитесь руками
Візьміть адресу тут, пройдіть сценарій і прочитайте, що ваш застосунок насправді надіслав, — заголовки, посилання й те, як лист виглядає, коли його показує не ваш власний поштовий клієнт. Дві речі, яких локальний перехоплювач пошти не ловить:
- Справжня доставка. Лист проходить справжній шлях SMTP, тож неправильно налаштований відправник падає тут, а не на проді.
- Вигляд для сторонньої людини. Посилання, які працюють лише у вашій сесії, картинки, що не завантажуються, посилання «відписатися», яке веде на localhost, — усе це видно одразу.
Якщо ваш застосунок надсилає файли, подивіться й на попередження про вкладення: ваші користувачі побачать рівно ті самі.
Коли це має бути автоматично
Розбирати натомість нашу сторінку того не варте, навіть коли воно працює: це крихко, ніде не описано, і це рівно той шаблон трафіку, який урешті блокують.
Тестування шляхів відмови
Цікаві збої — не «коректна адреса працює». Варто покрити:
- Адресу на домені без MX-запису: доставка не вдається, хоч сама адреса цілком правильна. Ваш код має ці випадки розрізняти. Перевірка домену.
- Інтернаціоналізований домен в обох формах — юнікодній і
xn--. Більшість перевірячів одну відхиляє, а другу приймає, і зазвичай не ту, на яку ви очікували, — перетворювач punycode. - Варіанти Gmail із крапками й плюсом. Якщо ваша перевірка унікальності порівнює сирі рядки, одна людина зареєструє необмежену кількість записів. Спершу нормалізуйте — та сторінка робить рівно те, що має робити ваша перевірка.
- Дуже довгу локальну частину. Стандарт дозволяє 64 символи; чимало форм мовчки обрізають на двадцяти й зберігають те, що вже нікуди не веде.
Одна річ, яку варто зробити, а не протестувати
Якщо ваш продукт не приймає одноразових адрес, відмовляйте зрозуміло. «Недійсна адреса» для цілком коректної адреси — найзаплутаніша помилка в цій категорії: людина перевіряє написання, набирає ще раз і отримує те саме повідомлення. «Ми не приймаємо тимчасові адреси» займає стільки ж місця й знімає плутанину.