Expected and actual mismatch

[David Gardiner]

When I run the following test

<TestFixture()> _
Public Class AddAuditPresenterTest

Dim mocks As MockRepository
Dim Dao As IAuditDao
Dim View As IAddAuditView

<SetUp()> Public Sub SetUp()
mocks = New MockRepository()
Dao = mocks.CreateMock(Of IAuditDao)()
View = mocks.CreateMock(Of IAddAuditView)()

End Sub

<Test()> Public Sub AddNewAudit()
Dim p As New AddAuditPresenter(View, Dao)

Dim a As New Audit
Dim s As New Section
a.Sections.Add(s)
s.FromAudit = a

'Using mocks.Record

Expect.Call(Dao.SaveOrUpdate(a)).Return(a)

' End Using

'Using mocks.Playback

mocks.ReplayAll()
p.Initview()

Dim newAudit As Audit = p.AddAudit(TestGlobals.DepartmentId)

Assert.IsNotNull(a)
'End Using
End Sub

End Class

it fails with this error:

Starting the MbUnit Test Execution
Exploring AuditMaker.UnitTests, Version=1.0.0.0, Culture=neutral,
PublicKeyToken=885d1150065cd4b3
MbUnit 1.0.2700.29885 Addin
Found 1 tests
AddAuditPresenter: AddAudit
[failure] AddAuditPresenterTest.SetUp.AddNewAudit
TestCase 'AddAuditPresenterTest.SetUp.AddNewAudit'
failed: IDao`2.SaveOrUpdate(UniSA.Flc.AuditMaker.Core.Domain.Audit);
Expected #0, Actual #1.
IDao`2.SaveOrUpdate(UniSA.Flc.AuditMaker.Core.Domain.Audit); Expected
#1, Actual #0.
Rhino.Mocks.Exceptions.ExpectationViolationException
Message: IDao`2.SaveOrUpdate(UniSA.Flc.AuditMaker.Core.Domain.Audit);
Expected #0, Actual #1.
IDao`2.SaveOrUpdate(UniSA.Flc.AuditMaker.Core.Domain.Audit); Expected
#1, Actual #0.
Source: Rhino.Mocks
StackTrace:
at
Rhino.Mocks.MethodRecorders.UnorderedMethodRecorder.DoGetRecordedExpectation(IInvocation
invocation, Object proxy, MethodInfo method, Object[] args)
at
Rhino.Mocks.MethodRecorders.MethodRecorderBase.GetRecordedExpectation(IInvocation
invocation, Object proxy, MethodInfo method, Object[] args)
at Rhino.Mocks.Impl.ReplayMockState.DoMethodCall(IInvocation
invocation, MethodInfo method, Object[] args)
at Rhino.Mocks.Impl.ReplayMockState.MethodCall(IInvocation
invocation, MethodInfo method, Object[] args)
at Rhino.Mocks.MockRepository.MethodCall(IInvocation invocation,
Object proxy, MethodInfo method, Object[] args)
at Rhino.Mocks.Impl.RhinoInterceptor.Intercept(IInvocation
invocation)
at Castle.DynamicProxy.AbstractInvocation.Proceed()
at IAuditDaoProxye65fd9806bd5404280b0f0edf57766a8.SaveOrUpdate(Audit
entity)
D:\Visual Studio Projects\2007\AuditMaker\Main\Source\Code\AuditMaker
\AuditMaker.Presenters\AddAuditPresenter.vb(38,0): at
UniSA.Flc.AuditMaker.Presenters.AddAuditPresenter.AddAudit(Int32
departmentId)
D:\Visual Studio Projects\2007\AuditMaker\Main\Source\Code\AuditMaker
\UnitTests\Presenters\AddAuditPresenterTest.vb(63,0): at
AuditMaker.UnitTests.AddAuditPresenterTest.AddNewAudit()

I don't understand why it says it says it found an unexpected
"IDao`2.SaveOrUpdate", and also it didn't find a "IDao`2.SaveOrUpdate"
that it was expecting.

I usually use the Using/End Using code, but it also fails with the old-
fashioned syntax as shown above.

-dave

[David Gardiner]

I finally figured out the cause (not before compiling the Rhino Mocks
source and stepping through the debugger a few times!)

The problem was caused by the expected method returning a different
result.

Adding the IgnoreArguments() method on the end of the Expect.Call
solved this.

Next time what I would like is a bit more detail as to why an expected
method wasn't matched.. If it were possible to indicate that the
arguments didn't match that would be a lot more useful.

thanks,
-dave

[Josh Flanagan]

If you would like to see more details of the expectations that you are recording and matching, try adding this in your test setup:
RhinoMocks.Logger = New TextWriterExpectationLogger (Console.Out)

You should then see all the logging messages in the Output window of Visual Studio.

[David Gardiner]

That's a good tip - i did try that out, but I'd still appreciate a bit
more detail as to why a method was not matched.

-dave

[Josh Flanagan]

It does try to tell you what didn't match in the exception message. The problem is that your Audit class does not have a meaningful ToString method.

 Notice:
IDao`2.SaveOrUpdate(UniSA.Flc.AuditMaker.Core

.Domain.Audit);
Expected #0, Actual #1.
IDao`2.SaveOrUpdate(UniSA.Flc.AuditMaker.Core.Domain.Audit); Expected
#1, Actual #0.

The message says that it found the first method call, and wasn't expecting it. It then says it was expecting the second method call, but it never happened.
Unfortunately, both method calls look the same, because your Audit class's ToString method just prints out the class name, which will be the same in both calls.

Try overriding ToString on UniSA.Flc.AuditMaker.Core.Domain.Audit to see if the error message is more descriptive.

On 7/4/07, David Gardiner <David.R....@gmail.com > wrote:

[Jeff Brown]

Just thinking off into the blue, but I wonder whether we could via reflection detect if the default implementation of ToString() is being used and if so revert to a different reflective implementation of ToString(). In general it's best if the class implementor does the work but perhaps we can help things along somewhat from the outside. This has occurred to me for MbUnit Gallio. Specifically, providing an extensible formatting and parsing service for objects in tests. Thus the tests could encapsulate these concerns when it doesn't make sense (or is not possible) to put them into the implementation itself.

Jeff.

________________________________

[Ayende Rahien]

Probably a good idea. This is certainly possible.

[Josh Flanagan]

It could try evaluating any existing DebuggerDisplayAttribute when available, although the benefit may be negligible, as it is still in the hands of the implementor.
However, without any help from the implementor, it will be difficult to determine which fields are worth displaying, and maybe too noisy to dump everything.

On 7/4/07, Jeff Brown <Je...@ingenio.com> wrote:

[Fabian Schmied]

> Just thinking off into the blue, but I wonder whether we could via reflection detect
> if the default implementation of ToString() is being used and if so revert to a
> different reflective implementation of ToString(). In general it's best if the class
> implementor does the work but perhaps we can help things along somewhat
> from the outside. This has occurred to me for MbUnit Gallio. Specifically,
> providing an extensible formatting and parsing service for objects in tests. Thus
> the tests could encapsulate these concerns when it doesn't make sense (or is
> not possible) to put them into the implementation itself.

Interesting, but (having run into the same issue as David a few times)
for the beginning, it would probably suffice to just indicate that
(and which) argument instance(s) differ.

Fabian