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("[email protected]");
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
A Mail message generally consists of a message body, which is the text the sender wrote, and special data specifying recipients, transport medium, etc., very much like what you see when you look at a letter's envelope.
C# Unit Tests with Mocks provide an easy way of reducing unwanted dependencies when writing unit tests. One of the best and shortest definition for mocking is mocking is creating objects that simulate the behavior of real objects.
MailMessage Class represents an email messages that can be sent using SmtpClient class. Instances of the MailMessage class are used to construct email messages that are transmitted to an SMTP server for delivery using the SmtpClient class.
Allows applications to send email by using the Simple Mail Transfer Protocol (SMTP). The SmtpClient type is obsolete on some platforms and not recommended on others; for more information, see the Remarks section.
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:
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);
}
}
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:
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]"));
}
}
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:
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);
}
}
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:
class MockEmailService : IEmailService {
private EmailMessage sentMessage;;
public SentMailMessage { get { return sentMessage; } }
public void SendEmail(MailMessage message) {
sentMessage = message;
}
}
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.
You will end up mocking several different classes here (at least two). First, you need a wrapper around the MailMessage class. I would create an interface for the wrapper, then have the wrapper implement the interface. In your test, you will mock up the interface. Second, you'll provide a mock implementation as an expectation to the mocked interface for the MailAddressCollection. Since MailAddressCollection implements Collection<MailAddress>
, this should be fairly straight-forward. If mocking the MailAddressCollection is problematic due to additional properties (I didn't check), you could have your wrapper return it as an IList<MailAddress>
, which as an interface should be easy to mock.
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 ) );
...
}
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With