Как мне тестировать отправку электронной почты с контроллера? - PullRequest
6 голосов
/ 26 мая 2010

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

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

Связующие модели делают свое дело, и мой метод действия принимает опубликованные данные в качестве модели. Затем метод действия проанализирует модель и с помощью smtp отправит электронное письмо администратору веб-сайта, сообщая ему, что кто-то заполнил контактную форму на их сайте.

Теперь к вопросу .... Чтобы проверить это, я был бы прав при создании интерфейса IMessageService , который имеет метод Отправить (emailAddress, message) для принятия адрес электронной почты и тело сообщения. Реализуйте интерфейс в конкретном классе и позвольте этому классу иметь дело с SMTP-файлами и фактически отправлять почту.

Если я добавлю интерфейс в качестве параметра в конструктор моего контроллера, я смогу затем использовать DI и IoC для внедрения конкретного класса в контроллер. Но при модульном тестировании я могу создать фальшивую или фиктивную версию моего IMessageService и сделать утверждения на этот счет.

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

Ответы [ 4 ]

2 голосов
/ 26 мая 2010

Вам все еще нужно проверить свой класс, который вызывает почтовую программу. Я полагаю, что вы можете сделать немного того и другого. Обычно я создаю интерфейс IMailClient и обертку вокруг SmtpClient, которая реализует интерфейс. Используйте (и внедрите) интерфейс в прокси-классе, который знает, как создать сообщение и отправить его (он может иметь несколько методов фабричного типа, которые могут создавать несколько различных типов сообщений). Подкладка вокруг SmtpClient действительно должна быть именно такой, поэтому нет необходимости в ее модульном тестировании. При тестировании прокси-класса вы можете издеваться над своей прокладкой, а при тестировании контроллеров - надсудить прокси-класс.

1 голос
/ 26 мая 2010

Я думаю, что вы на правильном пути. Не беспокойтесь о серверах smtp или о чем-либо еще. Просто модульный тест, что вам нужно. Пусть тесты скажут вам, что вам нужно. Когда вы приступаете к тестированию фактического Send(emailAddress, message), тогда вы можете беспокоиться о том, как вы на самом деле отправите сообщение администратору.

1 голос
/ 26 мая 2010

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

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

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

1 голос
/ 26 мая 2010

Подход, который вы описываете, хорошо работал для меня в прошлом. Я работал над проектом, который взаимодействовал с API веб-службы MS Dynamics CRM. Я хотел провести модульное тестирование своего кода, но у меня не было желания проводить модульное тестирование веб-службы. Я следовал именно тому процессу, который вы описываете, но с насмешкой над веб-службой, а не с доставкой почты Это сработало очень хорошо.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...