I’ve got an interface being mocked:
public interface IEmailService
{
void SendAsHtml(string to, string from, string subject, string notification);
void SendAsHtml(string to, string from, string subject, string notification, string[] cc);
}
It was previously a single method with a params string[] cc but I split the methods up while attempting to figure out what is wrong on our build server. What I really want is a strict mock, but I am running it as dynamic right now so I can compare results, using the following verification:
emailService.Verify(es => es.SendAsHtml(accountEmail, fromEmail, subject, expectedEmailString));
The parameters match up on accountEmail, fromEmail and subject – it is the expectedEmailString (constructed in the method under test via string.Format) that does not seem to be working. I’ve written expected and actual values to the console while testing and when viewing the output they appear to be the same on the build server. Here is the test failure (this is from a variation where I tried to force an ordinal comparison):
Expected invocation on the mock at least once, but was never
performed: es => es.SendAsHtml(.accountEmail, .fromEmail, .subject,
It.Is(s => s.Equals(.expectedEmailString,
StringComparison.Ordinal))) No setups configured.Performed invocations: IEmailService.SendAsHtml(“user@test.com”,
“sender@email.net”, “asdfasdf”, “long html string”)
Here are what I think are the relevant setups (all injected directly to the controller under test):
var getPersonalAccount = new Mock<IGetPersonalAccount>(MockBehavior.Strict);
getPersonalAccount.Setup(gpa => gpa.WithAccountId(userAccountId).Execute()).Returns(account);
var emailService = new Mock<IEmailService>();
var trialSettings = new Mock<TrialSettings>(MockBehavior.Strict);
trialSettings.Setup(ts => ts.Length).Returns(trialLength);
trialSettings.Setup(ts => ts.FromEmail).Returns(fromEmail);
trialSettings.Setup(ts => ts.Subject).Returns(subject);
Subject and from address are returned by trial settings, and the to email address is taken off the account. The message body is formatted with a values from the account as well.
Relevant bits:
- TeamCity 7.1 (build 23907) – tried both nunit 2.5.10 and 2.6 test
runners - .NET 4
- NUnit 2.5.10.11092
- Moq 4.0.10827.0
So, I ended up just removing the “whole string” check on the giant HTML string and checking only to confirm that the values we are injecting into the string (via string.format) are there. This passes both locally and on the server. It’s not ideal, but I guess its not the worst thing in the world either.