Как сделать макет System.Net.Mail MailMessage?

Ответ 1

Зачем смеяться над MailMessage? SmtpClient получает MailMessages и отправляет их; что класс, который я хотел бы обернуть для целей тестирования. Итак, если вы пишете какую-то систему, в которой размещаются ордеры, если вы пытаетесь проверить, что ваш OrderService всегда будет отправлять электронные письма при размещении заказа, у вас будет класс, похожий на следующий:

class OrderService : IOrderSerivce 
{
    private IEmailService _mailer;
    public OrderService(IEmailService mailSvc) 
    {
        this. _mailer = mailSvc;
    }

    public void SubmitOrder(Order order) 
    {
        // other order-related code here

        System.Net.Mail.MailMessage confirmationEmail = ... // create the confirmation email
        _mailer.SendEmail(confirmationEmail);
    } 

}

При реализации IEmailService по умолчанию, использующей SmtpClient:

Таким образом, когда вы идете писать свой unit test, вы проверяете поведение кода, который использует классы SmtpClient/EmailMessage, а не поведение классов SmtpClient/EmailMessage:

public Class When_an_order_is_placed
{
    [Setup]
    public void TestSetup() {
        Order o = CreateTestOrder();
        mockedEmailService = CreateTestEmailService(); // this is what you want to mock
        IOrderService orderService = CreateTestOrderService(mockedEmailService);
        orderService.SubmitOrder(o);
    } 

    [Test]
    public void A_confirmation_email_should_be_sent() {
        Assert.IsTrue(mockedEmailService.SentMailMessage != null);
    }


    [Test]
    public void The_email_should_go_to_the_customer() {
        Assert.IsTrue(mockedEmailService.SentMailMessage.To.Contains("[email protected]"));
    }

}

Изменить: чтобы ответить на ваши комментарии ниже, вам понадобятся две отдельные реализации EmailService - только один будет использовать SmtpClient, который вы использовали бы в своем коде приложения:

class EmailService : IEmailService {
    private SmtpClient client;

    public EmailService() {
        client = new SmtpClient();
        object settings = ConfigurationManager.AppSettings["SMTP"];
        // assign settings to SmtpClient, and set any other behavior you 
        // from SmtpClient in your application, such as ssl, host, credentials, 
        // delivery method, etc
    }

    public void SendEmail(MailMessage message) {
        client.Send(message);
    }

}

Ваша фальшивая/фальшивая служба электронной почты (вам не нужна фальшивая инфраструктура для этого, но она помогает) не будет касаться SmtpClient или SmtpSettings; он только фиксирует тот факт, что в какой-то момент электронное письмо было отправлено через SendEmail. Затем вы можете использовать это, чтобы проверить, вызывался или нет SendEmail, и с какими параметрами:

class MockEmailService : IEmailService {
    private EmailMessage sentMessage;;

    public SentMailMessage { get { return sentMessage; } }

    public void SendEmail(MailMessage message) {
        sentMessage = message;
    }

}

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

Ответ 2

В итоге вы будете издеваться над несколькими разными классами (не менее двух). Во-первых, вам нужна оболочка вокруг класса MailMessage. Я бы создал интерфейс для обертки, а затем интерфейс оболочки реализовал оболочку. В вашем тесте вы будете макетировать интерфейс. Во-вторых, вы предоставите макетную реализацию в качестве ожидания для издевающегося интерфейса для MailAddressCollection. Поскольку MailAddressCollection реализует Collection<MailAddress>, это должно быть довольно прямолинейным. Если издевательство над MailAddressCollection является проблематичным из-за дополнительных свойств (я не проверял), вы могли бы заставить свою обертку вернуть ее как IList<MailAddress>, которая, как интерфейс, должна быть легко издеваться.

public interface IMailMessageWrapper
{
    MailAddressCollection To { get; }
}

public class MailMessageWrapper
{
    private MailMessage Message { get; set; }

    public MailMessageWrapper( MailMessage message )
    {
        this.Message = message;
    }

    public MailAddressCollection To
    {
        get { return this.Message.To; }
    }
}

// RhinoMock syntax, sorry -- but I don't use Moq
public void MessageToTest()
{
     var message = MockRepository.GenerateMock<IMailMessageWrapper>()
     var to = MockRepository.GenerateMock<MailAddressCollection>();

     var expectedAddress = "[email protected]";

     message.Expect( m => m.To ).Return( to ).Repeat.Any();
     to.Expect( t => t.Add( expectedAddress ) );
     ...
}

Ответ 3

Отказ от ответственности: я работаю на Typemock Вместо того, чтобы найти какой-то хак, вы можете использовать Typemock Isolator, чтобы просто подделать этот класс только в одной строке кода:

var fakeMailMessage = Isolate.Fake.Instance<MailMessage>();

Затем вы можете установить на нем поведение, используя Isolate.WhenCalled

Ответ 4

В .NET 4.0 вы можете использовать "duck-typing" для передачи другого класса вместо "System.Net.Mail". Но в более ранней версии, я боюсь, что нет другого способа, кроме создания обертки вокруг "System.Net.Mail" над макетным классом.

Если это другой (лучший) способ, я бы хотел его изучить:).

EDIT:

public interface IMailWrapper {
    /* members used from System.Net.Mail class */
}

public class MailWrapper {
    private System.Net.Mail original;
    public MailWrapper( System.Net.Mail original ) {
        this.original = original;
    }

    /* members used from System.Net.Mail class delegated to "original" */
}

public class MockMailWrapper {
   /* mocked members used from System.Net.Mail class */
}


void YourMethodUsingMail( IMailWrapper mail ) {
    /* do something */
}