Придумайте тесты для валидации email

Я думаю многие сталкивались с классической задачей "протестировать форму регистрации" логин + email + проль.

В данном случае инетерес предаставляет именно поле email.
Какие для такого теста можно придумать тестовые данные? есть собачка, нет собачки, есть точка для доменной зоны (.com) нет точки...

Сегодня нашёл в интернете интересную статью о том как программисты мерялись валидаторами email. Набор тестовых данных впечатлил.
http://www.dominicsayers.com/isemail/ - статья
http://www.dominicsa...ail/results.php - результаты.
(http://code.google.com/p/isemail/) - исходники.

Особо инетресны случаи, когда email вроде...
first.last@[IPv6:::12.34.56.78] - корректный email ))
first.(")middle.last(")@iana.org - корректный email ))
test@example - снова, согласно RFC, корректный email ))

Серьёзно ребята к делу подошли. Меня хватило только на один стандарт, затем составил набор правил и набор векторов.
Больше к ним не возвращался. Теперь стоит пересмотреть подход. Благодарю за ссылки!

P.S. В общем было бы здорово составить такие датасеты для всех стандартных случаев. Для того, что бы каждому заново не приходилось изобретать велосипед.

Я в своё время отказалась от анализа RFC при тестировании полей е-мейл.
Причина в том, что поддерживаемый стандартом синтаксис не поддерживается большинством почтовых серверов, а "корректный" е-мейл test@example в обычном ПО (чаще всего это формы регистрации) проходить НЕ должен.

Поэтому, с точки зрения изучения стандартов - прикольно, с точки зрения практической применимости - неприменимо.

Я думаю многие сталкивались с классической задачей "протестировать форму регистрации" логин + email + проль.

Сегодня нашёл в интернете интересную статью о том как программисты мерялись валидаторами email. Набор тестовых данных впечатлил.
http://www.dominicsayers.com/isemail/ - статья
http://www.dominicsa...ail/results.php - результаты.
(http://code.google.com/p/isemail/) - исходники.

Полезно было бы собрать базу такого рода тестовых случаев для стандартных полей .. УХ! )

Я в своё время отказалась от анализа RFC при тестировании полей е-мейл.
Причина в том, что поддерживаемый стандартом синтаксис не поддерживается большинством почтовых серверов, а "корректный" е-мейл test@example в обычном ПО (чаще всего это формы регистрации) проходить НЕ должен.

Поэтому, с точки зрения изучения стандартов - прикольно, с точки зрения практической применимости - неприменимо.

Не согласен. Приложения бывают разные. А тут рассматривается общий случай.
В целом конечно же, если приложение не специфично, то стандарты можно "упростить".
Кстати, можно полюбопытствовать, чем Вы руководствовались при выборе тестовых данных, если отказались от рассмотрения стандартов?

Я в своё время отказалась от анализа RFC при тестировании полей е-мейл.
Причина в том, что поддерживаемый стандартом синтаксис не поддерживается большинством почтовых серверов, а "корректный" е-мейл test@example в обычном ПО (чаще всего это формы регистрации) проходить НЕ должен.

Поэтому, с точки зрения изучения стандартов - прикольно, с точки зрения практической применимости - неприменимо.

Наташа, полностью согласен!
Лично не понимаю, почему вдруг у тестировщиков "заскок", что какая-то програмулька, при регистрации обязана поддерживать все возможные по RFC адреса. НЕТ НЕТ и НЕТ. Если моя программа понимает только адреса типа "четыре цифры, собака, goggle.com" - то это правильно. Потому, что так задумано. И такие адреса не противоречат RFC, а следовательно будут поняты любым почовым сервером.
Ошибкой будет, если принимается _невалидный_ адрес.

Другое дело, если вы пишите ПО почтового сервера. Тады да, обязан понимать.

Так что, резюме, если вы убьёте кучу времени на поиск и составление хитро*опых адресов и окажется, что ваша программа не понимает что-то типа

first(Welcome to the ("wonderful" (!)) world of email)@iana.org

. Вы придете к разработчику с багом, а он ваш пошлёт подальше - он будет абсолютно прав. Не занимайтесь ерундой.

Овчинка выделки не стоит

[quote name='LeshaL' timestamp='1296750343' post='83895']
Лично не понимаю, почему вдруг у тестировщиков "заскок", что какая-то програмулька, при регистрации обязана поддерживать все возможные по RFC адреса. НЕТ НЕТ и НЕТ. Если моя программа понимает только адреса типа "четыре цифры, собака, goggle.com" - то это правильно. Потому, что так задумано. И такие адреса не противоречат RFC, а следовательно будут поняты любым почовым сервером.
Ошибкой будет, если принимается _невалидный_ адрес.

Так что, резюме, если вы убьёте кучу времени на поиск и составление хитро*опых адресов и окажется, что ваша программа не понимает что-то типа [quote]first(Welcome to the ("wonderful" (!)) world of email)@iana.org[/quote]. Вы придете к разработчику с багом, а он ваш пошлёт подальше - он будет абсолютно прав. Не занимайтесь ерундой.
[/quote]
По-моему ситуация немного обратная. Если программа понимает только "адреса типа 'четыре цифры, собака, goggle.com'" - отлично. Но если тестирование black-box, и есть возможность проверить как можно более случаев - это тоже прекрасно, вдруг программист реализовал валидацию, основываясь на стандартах. Если поле мэйла примет "что-то типа [quote]first(Welcome to the ("wonderful" (!)) world of email)@iana.org" - но не сможет потом его корректно использовать, это как раз баг...
То есть, проблема не в том, что тестировщик прибежит с багом мол ваша прога не понимает э-мэйл по стандарту такому-то, а в том, что она как раз принимает что-то отличное от точки, собачки и доброго слова и потом не может с этим ничего сделать. Посему и хочется проверить множество вариантов, если есть такая возможность, желательно автоматически :)

По-моему ситуация немного обратная. Если программа понимает только "адреса типа 'четыре цифры, собака, goggle.com'" - отлично. Но если тестирование black-box, и есть возможность проверить как можно более случаев - это тоже прекрасно, вдруг программист реализовал валидацию, основываясь на стандартах. Если поле мэйла примет "что-то типа

first(Welcome to the ("wonderful" (!)) world of email)@iana.org"

- но не сможет потом его корректно использовать, это как раз баг...
То есть, проблема не в том, что тестировщик прибежит с багом мол ваша прога не понимает э-мэйл по стандарту такому-то, а в том, что она как раз принимает что-то отличное от точки, собачки и доброго слова и потом не может с этим ничего сделать. Посему и хочется проверить множество вариантов, если есть такая возможность, желательно автоматически :)

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

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

на вконтакте такое было http://www.webplanet...e_password.html

При подсчёте статистики мы не рассматривали пароли короче шести символов, поскольку в настоящее время на сервисе, слава Дурову, имеется такое ограничение. Однако же один способ завести "ВКонтакте" короткий пароль мы всё-таки обнаружили.

Да, при создании аккаунта этот номер не пройдёт, и в поле пароля придётся вбить не менее шести символов. Но зато потом можно зайти в раздел настроек и задать в качестве нового пароля любую последовательность из двух и более символов, которая включает как минимум один знак !, $ или &. Причина состоит в том, что перечисленные знаки "ВКонтакте" превращает в пятисимвольные последовательности "!", "$" и "&".

Соответственно, нельзя задать пароль, который состоял бы более чем из шести знаков !, $ или &, поскольку в результате его длина как бы будет более 32 символов, что не допускается.

С этим связан ещё один забавный глюк "ВКонтакте". При создании нового аккаунта упомянутые чудо-символы никуда не перекодируются и сохраняются как есть. Поэтому можно задать и более длинный пароль, например, "!!!!!!!!". А вот поменять такой пароль через соответствующую форму уже не получится, поскольку старый пароль при вводе будет перекодирован, обрезан и признан неправильным.

А что будем делать, когда в зоне рф начнут создавать почтовые службы?

А что будем делать, когда в зоне рф начнут создавать почтовые службы?

Вообще этот .РФ придумали назло тестировщикам.
А зачем ещё?

164 теста как раз по RFC с объяснением кейсов:
http://isemail.info/...email/test/?all
[10:43:26] Alexei Barantsev: нет, вот про email: http://habrahabr.ru/post/175375/

164 теста как раз по RFC с объяснением кейсов:
http://isemail.info/...email/test/?all
[10:43:26] Alexei Barantsev: нет, вот про email: http://habrahabr.ru/post/175375/

спасибо большое, полезные ссылки. Может у вас еще есть какие полезные, форумы и т.п.

у меня только одна мысль -
НАФИГА?