Skip to Content

Не тестируй это. Почтовые сервисы

Далеко не в первый раз мне попадается вопрос: «Как создать большое количество email’ов для тестирования?». Вроде бы, вполне нормальный вопрос. Но вот ответы на него, порой, поражают воображение. Здесь все – от нелепого «используйте mailinator», до более-менее адекватного «ставьте плюсики в адресах GMail». И очень редко в этих обсуждениях всплывает мысль: «А почему бы не настроить свой почтовый сервер?» Мысль-то  здравая, только на автора сего еретического высказывания сразу набрасываются оппоненты со своими ничем не оправданными страхами и сомнениями, после чего отвечавший решает просто махнуть рукой, т.к. объяснять долго, много и лениво. Мне тоже лениво, но я все-таки объясню.

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

Мистика и почта

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

Отправка сообщения. Упрощенный вариант

Что же мы видим?  А видим мы то, что путь письма, отправленного из нашего приложения, на самом деле не так прост, как казалось. Сначала оно попадает на Relay-сервер, который помещает его в какое-нибудь хранилище и говорит отправителю «Чувак, все OK, BYE!», и затем начинает разыскивать, кому бы это письмо сбагрить. После того, как подходящая жертва найдена, с ней происходит еще один содержательный диалог:

- HELO, лови письмо.

- OK, BYE!

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

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

Но я уверен, что, даже посмотрев на картинку и прочитав мое куцое пояснение к ней, найдутся бесстрашные тестеры, которые скажут: «Ну и что? Не так уж все и сложно. Ну, подумаешь, еще пара каких-то серверов. Мы и поболе видали!» И специально для них у меня есть еще одна картинка…

Отправка сообщения в реальной жизни

… и парочка вопросов:

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

 а не очередной экскаватор переехал очередное оптоволокно,
       а не очередному блек листу не понравился ваш IP,
             а не админ с похмельным синдромом накосячил с маршрутами,
                а не…
Как?

Вы до сих пор считаете, что сэкономили кучу времени, отказавшись от установки почтового сервера у себя под боком? Серьезно?

А пока вы думаете над этими вопросами я расскажу вам, как сделать так, чтобы больше не пришлось их себе задавать.

Все очень просто. Сделайте себе тестовый почтовый сервер. Для этих целей можно использовать, к примеру, hMailServer. Он бесплатен. Прост в установке и настройке. Благодаря наличию IMAP к нему прикручивается любая веб морда. И в следующий раз, когда вам понадобится много почтовых адресов, достаточно будет вписать 2 строчки на одной из вкладок и не доставать окружающих расспросами.

hMailServer catch all address

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

Но если у вас нет вообще ни минутки свободного времени, и на работе вы ходите строем, а по вечерам вам некогда, т.к. пиво в баре греется дома семеро по лавкам плачут, то вы можете пойти на Codeplex и скачать там программку под названием smtp4dev. После этого запустить ее двойным кликом и отправлять письма Сергею Брину, Биллу Гейтсу и черту на кулички.

smtp4dev

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

Короче, господа тестировщики, прекращайте засорять интернет пространство спамом, направьте усилия, которые вы тратите на регистрацию сотен аккаунтов, в благое русло. И воздастся вам. Smile

++++++++--

 Интересная статья. Но

 Интересная статья. Но возникает сразу вопрос - ЗАЧЕМ?

Почему бы не зарегистрироваться в Google Apps и не использовать Гуглопочту с Вашим кастомным доменом?

Тем более, что Google предоставляет это почти бесплатно. Вернее бесплатно но с ограничениями. Но поверьте, этого Вам хватит с головой.

При необходимости Вы можете создать несколько почтовых аккаунтов вида (это всего лишь пример) user@iqa.com.ua. Для регистрации тестовый юзеров, которые потом не будут использоваться можно включить настройку "Удалять письма, которые пришли на не существующие адреса" (ну или как-то так)

Помимо этого, Вы получаете все плюсы Google почты (а так же документов и календаря)

Из личного опыта, пользуюсь уже более 3 лет и ни разу еще не пожалел, что сделал себе Google Apps

 

 

Можно, конечно, и Google

Можно, конечно, и Google Apps, можно даже mailinator'ом пользоваться. Но это:

а. Бессмысленно

б. Иногда даже вредно

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

Почему это вредно? Да потому, что "тестируя" всю эту чепуху вы вносите большой элемент случайности в результаты тестов. Что получается в итоге? А вот что:

- Письмо не дошло, а девелоперы на стороне отправителя логи не удосужились сделать. Как понять где ошибка? В случае Google Apps гугловый SMTP вам логи не даст. И даже при использовании корпоративного реелея вам нужно будет побегать, чтобы логи у админов выпросить.

- IPшник попал в блек лист. Все Ок. Курим 2 часа.

- Интернет в офисе исчез. Все Ок. Курим...

Ну и сценарии типа "отправить 2000 тысячи писем разным пользователям за 5 минут" вам ни один Google Apps не позволит проверить. Со специфическими настройками мейл сервера (например, Verify Names) тоже проблема.

И, вообще, пускать тестируемое приложение в интернет нужно по-минимуму. Если вопрос можно решить локально - решайте.

 

И это... имейте совесть в конце концов. Спама в почтовом трафике и так over 90%, а вы еще добавляете.

ИМХО все зависит только от

ИМХО все зависит только от цели тестирования, а здесь она толком и не описана...

Если надо проверить доставку письма с нашего сервера на почту клиента, то я как раз воспользуюсь сторонними почтовиками, включая как популярные сервисы, так и никому не известные по большому счету.

Причем в данном случае фраза "вы вместо того, чтобы тестировать взаимодействие вашего приложения с SMTP сервером, вы заодно "тестируете" два десятка почтовых серверов, лоад балансеров, днсов, маршрутиризаторов и еще кучу всего." будет целью тестирования. Мне надо проверить, чтобы почта приходила на любой почтовый сервис, который себе придумает клиент. И я буду тестировать это вариант случайности, которая может возникнуть по пути прохождения письма.

А вот если письма не доходят или надо "тестировать взаимодействие вашего приложения с SMTP сервером", то это просто совсем другой разговор и другое тестирование. Для этого у меня админы сами поднимут SMTP на наших серверах и нужной для этого конфигурацией, а мне останется только проконтролировать взаимодействие.

Если надо просто куча адресов e-mail для какой-то проверки, то я обычно использую или наш внутренний почтовик, почтовый сервис на личном хостинге (нагенерировать вагон адресов не долго, причем можно их потом и удалить благополучно) или тем же почтовиком Google, на котором сейчас несколько постоянных тестовых аккаунтов.

Хммм... вероятно, ваш

Хммм... вероятно, ваш комментарий подразумевает какое-то противоречие написанному в посте, но я, честно говоря,  не понял какое. Единственное, что идет вразрез с тем что я написал это:

Если надо просто куча адресов e-mail для какой-то проверки, то я обычно использую или наш внутренний почтовик, почтовый сервис на личном хостинге (нагенерировать вагон адресов не долго, причем можно их потом и удалить благополучно) или тем же почтовиком Google, на котором сейчас несколько постоянных тестовых аккаунтов.

Не нужны для этого ни внутренние почтовики, ни личный хостинг, ни гугл аппс, ни (как ни странно) куча аккаунтов. Не усложняйте себе жизнь.

Я пользуюсь FakeSMTP для

Я пользуюсь FakeSMTP для тестирования отправки почты
У smtp4dev возможностей конечно побольше, но она письма в utf-8 нормально не отображает

Отправить комментарий

  • Адреса страниц и электронной почты автоматически преобразуются в ссылки.
  • Доступны HTML теги: <a> <em> <strong> <cite> <code> <ul> <ol> <li> <dl> <dt> <dd>
  • Строки и параграфы переносятся автоматически.
  • Pairs of<blockquote> tags will be styled as a block that indicates a quotation.
  • Textual smileys will be replaced with graphical ones.

Подробнее о форматировании