Как протестировать поле email

Стратегия тестирования поля Email

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

1. Функциональное тестирование: Валидация формата

Основная проверка — соответствие спецификации RFC 5322 (Internet Message Format). Я использую позитивные и негативные тест-кейсы.

// Пример позитивных тестовых данных (должны проходить валидацию)
const validEmails = [
    'simple@example.com',
    'very.common@example.com',
    'disposable.style.email.with+symbol@example.com',
    'other.email-with-dash@example.com',
    'x@example.com', // минимальная длина локальной части
    'example-indeed@strange-example.com',
    'admin@mailserver1', // локальное доменное имя без TLD
    '" "@example.org', // пробел в кавычках
    '"john..doe"@example.org', // двойные точки в кавычках
    'user@[IPv6:2001:db8::1]' // адрес IPv6
];

// Пример негативных тестовых данных (должны вызывать ошибку)
const invalidEmails = [
    'plainaddress', // отсутствует @ и домен
    '@no-local-part.com', // отсутствует локальная часть
    'Outlook Contact <email@domain.com>', // угловые скобки
    'email.domain.com', // отсутствует @
    'email@domain@domain.com', // два символа @
    '.email@domain.com', // начинается с точки
    'email.@domain.com', // заканчивается точкой
    'email..email@domain.com', // двойная точка
    'あいうえお@domain.com', // Unicode без нормализации (зависит от требований)
    'email@domain', // отсутствует . в домене (зависит от требований)
    'email@-domain.com', // дефис в начале домена
    'email@domain..com' // двойная точка в домене
];

2. Тестирование граничных значений и длины

Критически важный аспект — проверка ограничений длины, определенных RFC и бизнес-логикой:

• Минимальная длина: Пустая строка, 1 символ в локальной части (a@b.c).
• Максимальная длина:

    *   Локальная часть: 64 символа (RFC)
    *   Домен: 255 символов (RFC)
    *   Полный email: 254 символа (практическое ограничение)

• Граничные случаи:

    *   Ровно 64 символа в локальной части.
    *   Ровно 255 символов в домене.
    *   Строка длиннее допустимого (должна быть обрезана или вызвать ошибку).

3. Тестирование с учетом состояния системы и интеграций

Поле email редко существует в вакууме. Необходимо проверить:

• Уникальность: Попытка регистрации с уже существующим в системе email.
• Подтверждение email: Отправка письма с токеном/ссылкой, срок жизни ссылки, повторная отправка.
• Изменение email: В личном кабинете пользователя, с повторным подтверждением.
• Восстановление пароля: Использование email как идентификатора.
• Интеграция с почтовыми сервисами: Обработка временных и одноразовых адресов (mailinator.com, 10minutemail.com) — часто блокируются на уровне бизнес-правил.

4. Нефункциональное тестирование

• Безопасность:

    *   **SQL-инъекция**: `' OR '1'='1'@example.com`.
    *   **XSS**: `"><script>alert()</script>@example.com`.
    *   **Поле ввода в HTML**: Проверка атрибутов `maxlength`, `type="email"`.
    *   **Санитизация данных**: Удаление лишних пробелов в начале/конце, преобразование регистра (обычно доменная часть не чувствительна к регистру).

• Удобство использования (UX):

    *   Автоматическое предложение домена при вводе.
    *   Подсказки (placeholder) и понятные сообщения об ошибках.
    *   Возможность вставить email из буфера обмена.
    *   Корректная работа на мобильных устройствах (удобная клавиатура).

• Производительность: Обработка очень длинных строк, массовая валидация списков.
• Локализация: Поддержка интернационализированных доменных имен (IDN) и Unicode в локальной части (RFC 6531), например, пользователь@россия.рф. Важно проверять нормализацию символов.

5. Автоматизация проверок

Для эффективного тестирования я автоматизирую проверки валидации, интегрируя их в CI/CD.

# Пример концепта автотеста на Python с использованием pytest и регулярных выражений
import re
import pytest

# Упрощенное регулярное выражение для базовой валидации
EMAIL_REGEX = r'^[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,}$'

def validate_email(email: str) -> bool:
    """Функция валидации email (упрощенный пример)."""
    if len(email) > 254:  # Проверка общей длины
        return False
    return re.match(EMAIL_REGEX, email) is not None

# Параметризованный тест
@pytest.mark.parametrize("email, expected", [
    ("test@example.com", True),   # позитивный
    ("invalid-email", False),     # негативный
    ("", False),                  # пустая строка
    ("a@b.c", True),              # граничное значение минимальной длины
    (f"{'a'*64}@example.com", False), # превышение длины локальной части
])
def test_email_validation(email, expected):
    assert validate_email(email) == expected

Ключевые выводы и рекомендации

• Не полагайтесь на одну регулярное выражение. Используйте проверенные библиотеки (например, для Python — email-validator).
• Согласуйте спецификацию с заказчиком. Нужна ли поддержка + в Gmail (user+tag@gmail.com) для создания алиасов? Блокировать ли одноразовые почтовые сервисы?
• Тестируйте не только фронтенд, но и бэкенд. Обязательна идентичная валидация на сервере для безопасности.
• Проверяйте ошибки на человеческом языке. Сообщение должно четко указывать на проблему: "Некорректный формат email", "Этот email уже зарегистрирован", "Доменная часть не может начинаться с дефиса".

Таким образом, полное тестирование поля email — это многослойный процесс, сочетающий строгое соблюдение стандартов, бизнес-логику, безопасность и внимание к пользовательскому опыту.