I have this dataAccess mock object and I'm trying to verify that one of its methods is being invoked, and that the argument passed into this method fulfills certain constraints. As best I can tell, this method is indeed being invoked, and with the constraints fulfilled. This line of the test throws a MockException:
data.Verify(d => d.InsertInvoice(It.Is<Invoice>(i => i.TermPaymentAmount == 0m)), Times.Once());
However, removing the constraint and accepting any invoice passes the test:
data.Verify(d => d.InsertInvoice(It.IsAny<Invoice>()), Times.Once());
I've created a test windows form that instantiates this test class, runs its .Setup() method, and then calls the method which I am wishing to test. I insert a breakpoint on the line of code where the mock object is failing the test
data.InsertInvoice(invoice);
to actually hover over the invoice, and I can confirm that its .TermPaymentAmount decimal property is indeed zero at the time the method is invoked.
Out of desperation, I even added a call back to my dataAccess mock:
data.Setup(d => d.InsertInvoice(It.IsAny<Invoice>())).Callback((Invoice inv) => System.Windows.Forms.MessageBox.Show(inv.TermPaymentAmount.ToString("G17")));
And this gives me a message box showing "0". This is really baffling me, and no one else in my shop has been able to figure this out. Any help would be appreciated.
A barely related question, which I should probably ask independently, is whether it is preferable to use Mock.Verify(...) as I have here, or to use Mock.Expect(...).Verifiable followed by Mock.VerifyAll() as I have seen other people doing? If the answer is situational, which situations would warrent the use of one over the other?
