So I have some SMTP stuff in my code and I am trying to unit test that method.
So I been trying to Mockup MailMessage but it never seems to work. I think none of the methods are virtual or abstract so I can’t use moq to mock it up :(.
So I guess I have to do it by hand and that’s where I am stuck.
*by hand I mean witting the interface and the wrapper but letting moq still mockup the interface.
I don’t know how to write my Interface and my Wrapper(a class that will implement the interface that will have the actual MailMessage code so when my real code runs it actually does the stuff it needs to do).
So first I am not sure how to setup my Interface. Lets take a look at one of the fields that I have to mockup.
MailMessage mail = new MailMessage();
mail.To.Add("test@hotmail.com");
so this is the first thing that I have to fake.
so looking at it I know that “To” is a property by hitting F12 over “To” it takes me to this line:
public MailAddressCollection To { get; }
So it is MailAddressCollection Property. But some how I am allowed to go further and do “Add”.
So now my question is in my interface what do I make?
do I make a property? Should this Property be MailAddressCollection?
Or should I have a method like?
void MailAddressCollection To(string email);
or
void string To.Add(string email);
Then how would my wrapper look?
So as you can see I am very confused. Since there is so many of them. I am guessing I just mockup the ones I am using.
edit code
I guess in in a true sense I would only have to test more the exceptions but I want to test to make sure if everything gets sent then it will get to response = success.
string response = null;
try
{
MembershipUser userName = Membership.GetUser(user);
string newPassword = userName.ResetPassword(securityAnswer);
MailMessage mail = new MailMessage();
mail.To.Add(userName.Email);
mail.From = new MailAddress(ConfigurationManager.AppSettings["FROMEMAIL"]);
mail.Subject = "Password Reset";
string body = userName + " Your Password has been reset. Your new temporary password is: " + newPassword;
mail.Body = body;
mail.IsBodyHtml = false;
SmtpClient smtp = new SmtpClient();
smtp.Host = ConfigurationManager.AppSettings["SMTP"];
smtp.Credentials = new System.Net.NetworkCredential(ConfigurationManager.AppSettings["FROMEMAIL"], ConfigurationManager.AppSettings["FROMPWD"]);
smtp.EnableSsl = true;
smtp.Port = Convert.ToInt32(ConfigurationManager.AppSettings["FROMPORT"]);
smtp.Send(mail);
response = "Success";
}
catch (ArgumentNullException ex)
{
response = ex.Message;
}
catch (ArgumentException ex)
{
response = ex.Message;
}
catch (ConfigurationErrorsException ex)
{
response = ex.Message;
}
catch (ObjectDisposedException ex)
{
response = ex.Message;
}
catch (InvalidOperationException ex)
{
response = ex.Message;
}
catch (SmtpFailedRecipientException ex)
{
response = ex.Message;
}
catch (SmtpException ex)
{
response = ex.Message;
}
return response;
}
Thanks
Why mock the MailMessage? The SmtpClient receives MailMessages and sends them out; that’s the class I’d want to wrap for testing purposes. So, if you’re writing some type of system that places Orders, if you’re trying to test that your OrderService always emails when an order is placed, you’d have a class similar to the following:
With the default implementation of IEmailService wrapping SmtpClient:
This way, when you go to write your unit test, you test the behavior of the code that uses the SmtpClient/EmailMessage classes, not the behavior of the SmtpClient/EmailMessage classes themselves:
Edit: to address your comments below, you’d want two separate implementations of EmailService – only one would use SmtpClient, which you’d use in your application code:
Your mocked/faked email service (you don’t need a mocking framework for this, but it helps) wouldn’t touch SmtpClient or SmtpSettings; it’d only record the fact that, at some point, an email was passed to it via SendEmail. You can then use this to test whether or not SendEmail was called, and with which parameters:
The actual testing of whether or not the email was sent to the SMTP Server and delivered should fall outside the bounds of your unit testing. You need to know whether this works, and you can set up a second set of tests to specifically test this (typically called Integration Tests), but these are distinct tests separate from the code that tests the core behavior of your application.