A different approach to Mock Verification

Scott Bellware has posted about the awkwardness of mock testing - I find that the syntaxes for mock frameworks feel awkward to me.

It is true that the Validation of calls and arguments are hidden in the setup part of the test and the verification is run automatically at the end of the test. Here is how you can have a more explicit validation using TypeMock. (Note: I am using the Generic Syntax of our coming version)

Implicit Validation 

[Test] public void SomeTest() { // mock next instance of TestedClass this happens in SomeObject.DoYourThing(); Mock m = Mock<TestedClass>.MockNextInstance(); // mock foo once m.ExpectAndReturn("foo", "yada yada"); // do our thing SomeObject test = new SomeObject(); test.DoYourThing(); // verify that foo was called once m.Verify(); }

Explicit Validation

[Test] public void SomeTest() { // mock next instance of TestedClass this happens in SomeObject.DoYourThing(); Mock m = Mock<TestedClass>.MockNextInstance(); // mock foo m.AlwaysReturn("foo", "yada yada"); // do our thing SomeObject test = new SomeObject(); test.DoYourThing(); // verify that foo was called once Assert.AreEqual(1, m.GetCallCount("foo")); }

There are 2 differences:

1. Using AlwaysReturn instead of ExpectAndReturn, this turns the mock into a stub.

2. Fetching and Asserting the amount of calls made, after the test for our verification.

 

Notice how using a remark solves Scott’s problem altogether

 

The downfall for using the explicit syntax are:

1. No Fast Fail - Using the explicit syntax we will not fail fast when foo was called twice (or with wrong arguments) that could lead to another failure in the test (as the code continued to run)

2. Concurrent Tests, We can’t use the concurrent features of Mocking (using VerifyWithTimeout) that enables testing multithreaded code without playing with joining threads  (just wait for a particular method in one thread to be called to signal that we can validate some data in the test thread)

Bookmark at:
Add 'A different approach to Mock Verification' to Del.icio.us Add 'A different approach to Mock Verification' to digg Add 'A different approach to Mock Verification' to reddit Add 'A different approach to Mock Verification' to Feed Me Links! Add 'A different approach to Mock Verification' to Technorati Add 'A different approach to Mock Verification' to Yahoo My Web Add 'A different approach to Mock Verification' to Newsvine Add 'A different approach to Mock Verification' to FURL Add 'A different approach to Mock Verification' to blinklist Add 'A different approach to Mock Verification' to My-Tuts 

16 April 2007 | .NET Tests | Comments | Print This Post

2 Responses to “A different approach to Mock Verification”

  1. 1 Scott Bellware 17 April 2007 @ 1:25 am

    I think the challenge here is that the method name is represented as a string. If there’s no alternative to this then it would be an annoying hindrance to refactoring.

  2. 2 Eli Lopian 17 April 2007 @ 9:24 am

    True,
    Although that is not the only challenge.
    Having void methods and validating arguments are another.

Leave a Reply

  1.  
  2.  
  3.  
Search Eli Lopian’s Blog (TypeMock)

Navigation

Recent Posts

Categories

Archives

Managment