Тест Outlook Recipient: всегда успешно / всегда отказов - PullRequest
Новая
       9

Тест Outlook Recipient: всегда успешно / всегда отказов

6 голосов
/ 25 мая 2011

Я пишу тесты JUnit и хотел бы иметь получателя электронной почты Outlook, который всегда будет успешным, и другого, который всегда будет считаться недоставленным.

Для «всегда успешно» я думаю, что SMTP-эквивалент NUL: был бы полезен.

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

Для "всегда отказов", я полагаю, я мог бы использовать im.a.nut@mycompany.com, но был бы открыт для более надежного метода, который не сломался бы, если бы мистер Нут присоединился к MyCompany.

Наряду с "всегда отказов", я был бы признателен за любые мысли о том, как и где искать сообщения "System Undeliverable". Должен ли я использовать тестовую учетную запись электронной почты? Или, может быть, насмешливый фреймворк для насмешки отказов?

РЕДАКТИРОВАТЬ: В соответствии с http://www.oracle.com/technetwork/java/faq-135477.html#bounce, отказов сообщения стандартизированы, но не получили широкого применения. Проверка адреса электронной почты не зависит от JavaMail. Вот как я отвечу на вопросы в последнем абзаце. Проверка учетной записи электронной почты может занять некоторое время, прежде чем она получит сообщение, и я не хочу блокировать сообщение, которое не гарантировано доставлено. Насмешка может иметь больше смысла.

1 Ответ

2 голосов
/ 27 мая 2011

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

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

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

Что касается обработки различных типов ответов, у меня был проект, в котором нам нужно было протестировать различные типы ответов на приглашения на собрания.Мы настроили серверные правила для разных адресов электронной почты, чтобы определенный созданный субъект или тело автоматически отвечали с принятием, отклонением и т. Д. Простое в настройке правило на стороне сервера - просто войдите в систему как этот пользователь (именно здесьПоддельный контроллер домена пригодится) открой outlook и настрой правило.Более сложные правила могут быть настроены как часть Exchange «Event Sink» .

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

...