Тестовые фикстуры для валидации email в реалистичных сценариях регистрации

Что обычно идёт не так с тестами валидации email

Большинство наборов тестов по валидации email выглядят надёжно, но всё равно терпят неудачу в продакшене, потому что реальные адреса — это бардак. Люди вставляют пробелы, используют плюс‑теги, смешивают регистры, добавляют завершающие точки или печатают быстро на мобильном и пропускают символ. Если ваши фикстуры покрывают только чистые, учебные адреса, вы тестируете мир, в котором ваши пользователи не живут.

Ещё одна распространённая проблема — тестирование только самого простого слоя: синтаксиса. Синтаксические проверки ловят явные ошибки, но многие проблемные регистрации используют адреса, которые выглядят валидными, но домены не существуют, у доменов нет почтовой настройки, или это disposable‑провайдеры, которые постоянно меняются. Набор тестов, который останавливается на regex, создаёт ложное чувство безопасности.

Цель — не блокировать всё подозрительное. Цель — остановить плохие регистрации, не блокируя реальных людей. Это означает тестирование с обеих сторон: отвергать то, что действительно нужно отвергнуть, и принимать распространённые легитимные паттерны (например, плюс‑адресацию и субдомены).

Эти паттерны ошибок повторяются снова и снова:

• Переобучение на одном формате (например, предположение, что все email — простые [email protected]).
• Полагание на живые DNS или SMTP‑проверки в unit‑тестах, что делает тесты флакиными.
• Рассмотрение deliverable как гарантированного да/нет, в то время как многие сигналы частичные.
• Забытие правил риска (disposable, spam‑ловушки, известные плохие домены) до появления мошенничества.
• Хардкодинг исходов для доменов, которые со временем меняют своё поведение.

Хорошие тесты покрывают слои, которые соответствуют тому, как работает валидация при реальной регистрации: синтаксис (правила в духе RFC), сигналы домена (существует ли домен, MX‑записи), сигналы почтового ящика (поведение catch‑all или шаблоны приёма) и сигналы риска (блок‑листы и обнаружение disposable).

Установите ожидания заранее: некоторые исходы вероятностны. Catch‑all домены могут принимать почту для любого имени без подтверждения существования конкретного ящика. Списки disposable меняются ежедневно. Даже инструменты уровня предприятия, такие как Verimail, могут возвращать рискованные сигналы, которые лучше обрабатывать продуктовыми правилами (разрешить, заблокировать или требовать доп. проверку), вместо того чтобы притворяться, что для каждого случая есть идеальный ответ.

Разбейте валидацию на тестируемые слои

Валидация email кажется одной проверкой, но на деле это цепочка маленьких проверок. Разделите эту цепочку на слои — и ваши тесты станут яснее и проще в поддержке. Это также помогает создавать фикстуры, которые соответствуют реальным вводам пользователей, а не случайным строкам.

Практичная модель слоёв выглядит так:

• Синтаксис: выглядит ли это как email (базовый формат и те правила RFC, которые поддерживает ваше приложение)?
• Домен и MX: существует ли домен и может ли он принимать почту (DNS и MX‑записи)?
• Тип провайдера: disposable‑провайдер, известный бесплатный почтовый сервис или корпоративный домен?
• Правила риска: ваши бизнес‑правила (блок‑лист, подсказки spam‑ловушек, подозрительные шаблоны, лимиты по частоте).

Не каждый слой следует тестировать одинаково. Некоторые слои — чистая логика и могут выполняться быстро и офлайн (синтаксис, большинство правил риска). Другие зависят от сети (DNS, MX‑lookup, realtime блок‑листы). Обращайтесь с ними по‑разному, чтобы набор тестов оставался стабильным.

Далее решите, что ваше приложение делает с результатами каждого слоя. Многие команды сводят всё к pass/fail и получают запутанные крайние случаи. Градация исходов обычно удобнее:

• valid: принять и продолжить
• risky: разрешить, но предупредить, добавить доп. верификацию или ограничить действия
• invalid: блокировать с понятным сообщением
• unknown: попросить пользователя попробовать позже или перейти на подтверждение по email

Практический пример: пользователь вводит [email protected]. Синтаксис проходит, но ваши правила опечаток отмечают это как рискованное. Вы можете разрешить регистрацию, но попросить подтвердить адрес. Если введён [email protected], синтаксис проходит, но домен или MX не проходят — значит вы блокируете.

Пишете тесты — сопоставляйте каждую фикстуру со слоем, который должен её поймать, и с ожидаемым исходом. Для сетевых слоёв предпочитайте краевые тесты (например, как вы обрабатываете ошибку DNS vs реальный результат no‑MX) и держите остальное как быстрые unit‑тесты. Если вы используете API вроде Verimail, вы можете отразить его многоступенчатые результаты (syntax, domain, MX, disposable‑проверки) в собственных ожиданиях по слоям.

Категории сценариев, которые стоит включить в фикстуры

Хорошие фикстуры для валидации email похожи на то, что реально вводят пользователи, а не на случайные строки. Создавая фикстуры вокруг нескольких понятных категорий, вы делаете тесты читабельными и легко заметите пропуски.

Держите эти основные категории в каждом наборе:

• Опечатки и ошибки форматирования: отсутствие @, двойной @@, пробелы в начале/конце, двойные точки, точка прямо перед @ и перестановка символов в известных доменах. Эти случаи должны быстро падать на слое синтаксиса до любых сетевых проверок.
• Мёртвые домены: домены, которые не существуют (NXDOMAIN), домены, которые существуют, но не имеют MX‑записей, и домены, которые резолвятся, но не настроены для почты. Эти случаи должны проваливаться на слое DNS/MX. Держите их в отдельном наборе фикстур, чтобы было ясно, что они ожидаемо недействительны.
• Catch‑all домены: домены, которые принимают почту для любого имени. Фиксируйте неоднозначный исход (синтаксис OK, домен OK, почтовый ящик неизвестен), вместо того чтобы считать это гарантированным успехом.
• Disposable‑провайдеры и похожие домены: несколько известных временных доменов, плюс похожие варианты (лишние слова, другой TLD или опечатка). Ожидайте, что они будут помечены как disposable, а не просто как корректный формат.
• Шаблоны spam‑ловушек (обращайтесь аккуратно): ролевые аккаунты типа admin@, support@, info@ и подозрительные шаблоны вроде длинных числовых строк. Тестируйте вашу политическую логику (разрешать, предупреждать или блокировать), вместо того чтобы считать их всегда плохими.

Чтобы категории были полезными, связывайте каждую фикстуру с ожидаемым решением, а не только с валидностью. Метки вроде syntax_invalid, domain_invalid, disposable_block, risky_allow_with_warning, unknown_catch_all упрощают интерпретацию ошибок.

Если вы используете валидатор API, например Verimail, сопоставляйте эти категории со стадиями пайплайна, которые вы ожидаете вызвать (syntax, domain checks, MX lookup, disposable blocklist match). Тогда упавший тест сообщит, какого рода ошибка произошла, а не просто что «что‑то сломалось».

Как проектировать реалистичные фикстуры (не случайные строки)

Хорошие фикстуры выглядят как реальные регистрации, а не как набор случайных символов. Когда тест падает, вы должны сразу понимать, что произошло и почему это важно.

Рассматривайте фикстуры как маленькие записи с согласованной структурой: входной email, ожидаемый исход (принять, отклонить или требовать доп. проверку) и короткая причина. Добавьте поле заметок для всего, что вы быстро забудете (почему выбран домен или какое поведение ожидается при смене провайдера).

Вот компактный пример, который можно скопировать в репозиторий:

[
  {
    "name": "typo_gmail_missing_dot",
    "input": "alex@gmailcom",
    "expected": "reject",
    "reason": "typo",
    "tags": ["typo"],
    "notes": "Missing dot in domain; should fail domain validation."
  },
  {
    "name": "disposable_known_provider",
    "input": "[email protected]",
    "expected": "reject",
    "reason": "disposable",
    "tags": ["disposable"],
    "notes": "Should be blocked by disposable provider list."
  }
]

Теги облегчают расширение набора. Вместо одного огромного файла держите небольшие именованные наборы по категориям (typos, dead domains, catch‑all, disposable, edge cases). Тогда вы сможете запускать только то, что нужно, например только disposable‑кейсы после обновления классификации.

Правила нормализации тоже должны быть в фикстурах, потому что пользователи вставляют «грязные» данные. Включите случаи, которые доказывают, что вы обрабатываете:

• Пробелы в начале и конце (trim до валидации)
• Заглавные буквы в домене (lowercase для части домена)
• Unicode и похожие символы (решите, что вы разрешаете, и протестируйте это)
• Плюс‑адресацию (определите, считаете ли вы её валидной)

Версионируйте фикстуры как код. Каждое новое добавление должно отвечать на один вопрос: какую ошибку оно предотвратило? Добавьте короткую заметку, требуйте ревью при изменениях и удаляйте дубликаты. Со временем фикстуры станут живой картой ошибок и атак, с которыми сталкивается ваша регистрация.

Если вы полагаетесь на ответ API (например, Verimail), храните прикреплённый ожидаемый ответ для каждой фикстуры и обновляйте его только при намеренной смене политики.

Как выбрать данные фикстур, которые останутся стабильными во времени

Проверки email касаются вещей, которые меняются без предупреждения: записи DNS, настройки почтовых серверов и экосистема disposable‑провайдеров. Если ваши фикстуры зависят от живого интернета, тесты будут падать в случайный вторник по причинам, не связанным с вашим кодом.

Начните с разделения того, что можно сделать детерминированным, и того, что нет. Синтаксические случаи просты: они не должны требовать сетевых вызовов. Сложность возникает с тем, что проверяет достижимость домена или почтового ящика.

Стабильный набор фикстур обычно формируется из нескольких источников:

• Зарезервированные домены для документации и тестов (хороши для синтаксических примеров, если вы стабы на сетевой шаг)
• Тестовые домены под вашим контролем (лучше всего, когда нужно предсказуемое поведение DNS и MX в разных окружениях)
• Записанные ответы (сохраните точный результат DNS‑lookup или API‑ответ, который вы получили, и воспроизводите его в тестах)
• Детерминированные не‑разрешающиеся сигналы, но только в стабах (домен, который не резолвится сегодня, может быть зарегистрирован завтра)
• Курируемый снапшот для disposable‑детекции, обновляемый по расписанию (ежемесячно или ежеквартально в зависимости от вашей толерантности к риску)

Избегайте использования реальных адресов людей в фикстурах, даже если они публичны. Используйте синтетические локальные части (например, "user" или "test") и явно фейковые имена. Это снижает риск утечки приватных данных и предотвращает случайные отправки, если тестовые данные попадут в логи или downstream‑системы.

Для сценариев мёртвых доменов самый стабильный подход — трактовать отказ DNS как тестовые данные, а не как живую реальность. Записывайте или мокаьте результат резолва (например, NXDOMAIN или отсутствие MX) и проверяйте, что логика обрабатывает это корректно. Живые мёртвые домены нестабильны, потому что домены могут быть куплены и настроены позже.

Disposable‑детекция требует особого ухода. Провайдеры появляются, исчезают и меняют домены часто. Держите версионированный снапшот вашего disposable‑списка (или классификаций вендора) и определите политику по дрейфу. Например: unit‑тесты запускаются против снапшота, а отдельная задача по расписанию проверяет изменения и создаёт задачу на ревью.

Запишите, какие фикстуры чувствительны ко времени и что вы будете делать при их изменении: обновлять снапшот, ослаблять утверждение или переводить кейс в контрактный тест. Если вы используете Verimail в продакшене, рассматривайте его ре‑тайм классификацию как то, что тестируется зафиксированными записями, а затем периодически проверяйте небольшим контролируемым live‑набором.

Автоматизация тестов: unit и контрактные тесты

Быстрые и надёжные тесты начинаются с частей валидации, которые не касаются сети. Рассматривайте валидатор как набор чистых функций (ввод —> вывод) и зафиксируйте контракт того, чего остальная часть приложения ожидает от них.

Unit‑тесты: делайте их чистыми и строгими

Unit‑тесты должны покрывать синтаксис и нормализацию, потому что на них легко влияют мелкие рефакторы. Примеры: удаление пробелов, приведение домена к нижнему регистру, отклонение двойного @ и обработка очевидных опечаток вроде пропущенной точки в домене.

При создании фикстур делайте каждую запись самодокументируемой: ввод, ожидаемое нормализованное значение (или пустое) и короткий код причины. Коды причин проще проверять, чем полные фразы.

Простой паттерн — table‑driven тесты: проходите по таблице фикстур и проверяйте и статус, и причину для каждого случая. Это держит файл тестов коротким, покрывая при этом много сценариев.

Контрактные тесты: зафиксируйте форму, а не формулировку

Контрактные тесты отвечают на другой вопрос: возвращает ли модуль валидации всегда одну и ту же структуру? Если одна команда ожидает { status, reason, normalized } и другая версия невзначай меняет её, вы получите баги, которые выглядят как случайные.

Контрактные тесты должны проверять такие вещи, как:

• Наличие обязательных полей (например: status, reason, normalized_email)
• Значения берутся из заранее определённого множества (например: valid, invalid, risky)
• Один и тот же ввод всегда даёт одну и ту же форму ответа
• Непредвиденные случаи падают безопасно (понятный код ошибки, а не краш)
• Опциональные поля остаются опциональными (не появляются иногда и исчезают в другое время)

Тесты на свойства (property‑based tests) тоже помогают. Вместо ручной записи каждой опечатки генерируйте «почти‑угаданные» вариации: лишние пробелы, перестановки символов вокруг @, повторяющиеся точки или смешанный регистр в домене. Цель — поймать баги парсера и крайние случаи, которые вы могли не предусмотреть.

Снапшот‑тестирование полезно для UI‑сообщений, но используйте его осторожно. Предпочитайте снапшоты стабильных кодов ошибок, а не полного текста. Если нужно фиксировать сообщения, делайте их короткими и консистентными, чтобы мелкие правки текста не ломали половину тестовой базы.

Автоматизация тестов: интеграция без флакинга

Именно на интеграционных тестах логика валидации email часто становится ненадёжной. Как только тест зависит от живого DNS, MX‑lookup или доступности стороннего сервиса, вы получаете случайные падения, не связанные с вашим кодом.

Сделайте CI детерминированным

Для повседневных прогонов в CI стремитесь к быстрым и воспроизводимым тестам. Относитесь к сети как к входным данным, которые вы контролируете.

Практический подход — мокать сетевую границу и проверять, что делает ваше приложение с каждым результатом. Если ваш сервис регистрации вызывает API валидатора, замените этот вызов заглушкой, возвращающей известные ответы для ваших фикстур. Вы всё ещё тестируете полный поток (контроллер, сервис, решение по политике, сообщение об ошибке), но не тестируете интернет.

Паттерны, которые обычно работают:

• Мокайте API‑вызовы в CI и возвращайте фиксированные ответы для каждой категории сценариев.
• Записывайте и воспроизводите DNS или MX‑исходы там, где это возможно, чтобы состояние «домен имеет MX» оставалось консистентным.
• Устанавливайте строгие таймауты в клиенте валидации и держите их одинаковыми в тестах.
• Ограничьте ретраи в тестах (обычно ноль или один), чтобы ошибки случайно не исправлялись и не маскировали проблемы.
• Проверяйте поведение, видимое пользователю (разрешить, блокировать или попробовать позже), вместо того чтобы проверять внутренние шаги.

Таймауты заслуживают особого внимания. Решите политику и протестируйте её явно: при таймауте считаете ли вы email недействительным или как неизвестный и позволяете пользователю продолжить с дополнительной верификацией? Оба подхода могут быть верны, но только если они последовательны.

Добавьте небольшой live‑плейн

Мокнутые тесты могут дрейфовать относительно реального мира. Домен, у которого были MX‑записи, может умереть; классификация disposable может измениться. Чтобы поймать дрейф, держите отдельную задачу, которая делает реальные сетевые вызовы, но не запускайте её на каждый PR.

Типичная настройка — ночной прогон или ручной workflow. Держите этот слой маленьким: несколько репрезентативных адресов по категориям (опечатки, мёртвые домены, catch‑all, disposable) достаточно, чтобы заметить дрейф без большого шума.

Если вы используете Verimail в продакшене, ваши CI‑тесты могут стабыть его ответ disposable: true для фикстуры вроде [email protected], и вы проверяете, что UI блокирует регистрацию и показывает нужное сообщение. Ночной прогон может делать реальные запросы к API с контролируемым набором адресов и уведомлять, если результаты поменялись — чтобы вы обновили фикстуры или политику до того, как на это обратят внимание пользователи.

Распространённые ловушки и ложная уверенность

Набор тестов может выглядеть насыщенно и при этом пропускать ошибки, которые бьют по продакшну. Самый большой риск — ложная уверенность: тесты проходят, но реальные пользователи блокируются или фейковые регистрации проходят.

Одна из ловушек — считать catch‑all доказательством существования почтового ящика. Catch‑all лишь означает, что домен принимает почту для любого адреса. Если вы автоматически одобряете всё на catch‑all, фикстуры тихо приучат вас принимать мусорные адреса.

Другая ловушка — использовать только regex и называть это валидацией. Regex ловит очевидные проблемы с форматом, но не скажет, существует ли домен, есть ли у него MX или принадлежит ли адрес disposable‑провайдеру. Если тесты покрывают лишь строковые шаблоны, вы тестируете ваш regex, а не поведение email.

Ещё частая ошибка — жёстко блокировать регистрации при временных проблемах DNS. Сети временно отваливаются. Если ваши тесты покрывают только сцену «DNS работает» и «DNS не работает», вы рискуете отвергать хороших пользователей во время краткой аутентификации. Лучше трактовать некоторые ошибки как unknown и ретраить или разрешать регистрацию с пометкой на последующую верификацию.

Международные домены и современные правила почты легко забыть. Плюс‑адресация (например, [email protected]) валидна и широко используется. У некоторых пользователей домены с не‑ASCII символами. Если ваши фикстуры никогда не включают такие случаи, вы выпустите валидатор, который ломается на нормальном вводе.

Несколько способов, как команды себя обманывают:

• Помечают catch‑all как доставляемый вместо «домен принимает почту».
• Считают любую ошибку DNS постоянной и блокируют регистрацию.
• Предполагают, что + недопустим или удаляют его неправильно.
• Полностью пропускают IDN‑кейсы.
• Тестируют только чистые, выдуманные адреса с идеальными доменами.

Практическая защита — разделять результаты на ясные бакеты (invalid, risky, unknown, valid) и тестировать переходы между ними. Инструменты вроде Verimail помогают, возвращая структурированные сигналы (syntax, domain, MX, disposable), что облегчает ассерты по поведению, а не по одному pass/fail.

Короткий чек‑лист перед релизом

Перед мерджем пробегитесь быстро по покрытию и уверенности. Цель — не протестировать каждый email на планете, а убедиться, что фикстуры ведут себя как реальные регистрации и падают предсказуемо.

Просмотрите набор фикстур по категориям. Если в категории только один‑два примера, маленькое изменение кода может повредить реальным пользователям, а тесты останутся зелёными. Стремитесь к небольшому кластерику случаев на категорию (практическая цель — 5–10 на категорию для опечаток, мёртвых доменов, catch‑all, disposable и ваших бизнес‑правил).

Используйте этот краткий чек‑лист:

• Каждая категория сценариев имеет минимальный набор примеров (практическая цель: 5–10 на категорию).
• Каждая фикстура включает ожидаемый исход (allow/block/needs verification) и однострочный reason, чтобы ошибки было легко понимать.
• Unit‑тесты полностью офлайн, а всё, что касается DNS, MX или внешних API, вынесено в контрактные или интеграционные тесты.
• Есть хотя бы один тест, симулирующий медленную зависимость (таймаут), чтобы подтвердить поведение (ретрай, fail‑closed или fail‑open) в соответствии с продуктовым решением.
• Есть план обновления данных о disposable‑провайдерах и способ заметить, когда реальный мир изменился.

Не пренебрегайте стабильностью. Тесты, зависящие от живых доменов, со временем портятся, а поведение catch‑all может измениться без предупреждения. Для unit‑тестов предпочитайте фикстуры без сети и держите поведение доменов в виде моков. Для интеграционных тестов ограничьте область и делайте их осознанными. Простой паттерн — небольшой ночной job, который прогоняет несколько известных кейсов против вашего валидатора, пока CI остаётся сосредоточенным на детерминированных unit‑тестах.

Пример: тестирование формы регистрации, которая блокирует disposable‑адреса

Обычная проблема SaaS: форма регистрации выглядит хорошо при ручном тестировании, но после запуска вы получаете волны спам‑регистраций. Многие используют disposable‑адреса — это плохие лиды, больше bounceов и запутанная база пользователей.

Практичный подход — определить чёткое поведение и зафиксировать его фикстурами. Например: блокировать disposable, отвергать мёртвые домены и разрешать (но предупреждать о) catch‑all.

Небольшой набор фикстур, покрывающий реалистичные входы без опоры на случайные строки:

• Опечатка: [email protected] (выглядит как реальный адрес, но домен с опечаткой)
• Мёртвый домен: [email protected] (используйте .invalid для домена, который никогда не должен резолвиться)
• Catch‑all: [email protected] (тут в моках трактуйте как catch‑all, а не как факт из DNS)
• Disposable: [email protected] (в моках помечайте как disposable, а не брать за настоящий провайдер)
• Нормальный: [email protected] (нормальный адрес для «happy path»)

Ключевая мысль — ваше приложение не должно пытаться доказывать catch‑all или disposable статус через публичный интернет в unit‑тестах. Вместо этого слой валидации должен возвращать нормализованный результат, на который ваша логика регистрации опирается.

Простые правила для endpoint регистрации:

• Если is_disposable = true: блокируйте регистрацию с понятной ошибкой
• Если domain_status = dead: отклоняйте и просите другой email
• Если is_catch_all = true: разрешайте регистрацию, но показывайте предупреждение (и рассматривайте доп. верификацию)

Чтобы CI был быстрым и предсказуемым, разделите тесты на два класса: быстрые unit‑тесты для логики принятия решений и замоканные интеграционные тесты для границы валидатора.

// Example: decision logic unit tests (no network)
const cases = [
  { email: "[email protected]", result: { is_disposable: true }, expect: "BLOCK" },
  { email: "[email protected]", result: { domain_status: "dead" }, expect: "REJECT" },
  { email: "[email protected]", result: { is_catch_all: true }, expect: "WARN" },
  { email: "[email protected]", result: { suggestion: "gmail.com" }, expect: "REJECT" },
  { email: "[email protected]", result: { ok: true }, expect: "ALLOW" },
];

for (const c of cases) {
  const decision = decideSignup(c.email, c.result);
  expect(decision).toBe(c.expect);
}

В CI мокнутый интеграционный тест может проверить, что ваш код регистрации вызывает валидатор ровно один раз и корректно обрабатывает таймауты и ошибки ответа, не делая реальных DNS или MX‑lookup запросов.

Если вы хотите реальные проверки (RFC‑совместный синтаксис, проверка домена, MX‑lookup и сопоставление с disposable/blocklist), не строя и не поддерживая эту логику самостоятельно, API‑владельцы по валидации email — хорошая альтернатива. Для команд, которые уже используют Verimail, простой паттерн — держать большинство тестов замоканными и детерминированными, а затем запускать небольшой набор контрактных проверок, чтобы убедиться, что интеграция с verimail.co по‑прежнему соответствует ожидаемой структуре ответа.