Блог

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

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

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

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

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

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

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

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

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

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

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