This project is read-only.

Using matchers

May 24, 2011 at 11:36 AM

How can I use matchers with NMock3? For example, while calling MethodWith....?

May 24, 2011 at 1:12 PM
Edited May 24, 2011 at 1:12 PM

Figured it out.

Use the Method instead of MethodWith.

For example, your mockobject interface defines a method called Print(Car someCar). You have written a matcher for matching cars called CarMatcher.

This is how your expectation can look like:

Car car = new Car("some stuff"); // This is just to give you the idea. You would probably have set this up and now want to expect that the Print method is called with a Car instance that matches what you have set up.

this.mockCar.Expects.One.Method(x => x.Print(car).With(new CarMatcher(car));

 

This should work just fine. Somehow, I don't like the feel of this, though. On one hand, I supply a lambda 'x => x.Print(car)' which says that the car instance that I specified above is to be passed, and on the other hand, I am setting up an matcher to compare....

Any better way to do this?

May 24, 2011 at 2:05 PM

No complaints anymore.

I can use null in the lambda expression like this: this.mockCar.Expects.One.Method(x => x.Print(null).With(new CarMatcher(car));

I figure it is okay to use either use null or default(Car) along with matchers.


May 26, 2011 at 3:00 AM

exactly right!  I use null in the lambda because it is just needed for the method signature.

I wish I had better documentation on the matchers as I realize they are a tricky part.  Please let me know if you find that the built in matchers aren't enough for you.  I don't know what you are trying to do but have a look at the LikeMatcher which (I think) makes you implement IComparable on your object.  This way you will be writing less unit test code (CarMatcher) and more business code (IComparable) that may help later on in the main app.  Also there is the PredicateMatcher which allows you to send the matching logic out to a private method....just some ideas.

May 26, 2011 at 11:06 AM

I look up the documentation for NMock2 as well as the cheat sheet for NMock3 now.

I like implementing matchers because of the ease in trouble shooting provided by the 'DescribeTo' method. I have got tons of matchers in my projects. (tons = just 5-10 :)). Moreover, we usually refrain from adding/modifying production code for unit tests. In that way, implementing IComparable is not preferred until it is needed in a business work flow. I agree that it can be handy, though.

PredicateMatcher sounds fine, but then again, we will/should create common methods since the same objects will be used from different test classes. I will definitely consider this for comparing one-off types.

Thank you :)

Oct 17, 2011 at 10:51 AM
Edited Oct 17, 2011 at 10:52 AM
It would be nice if  we could  specify expectations as mockCar.Expects.One.Method(x => x.Print(With(new CarMatcher(car)) ) similar to jmock2
jim4u wrote:

No complaints anymore.

I can use null in the lambda expression like this: this.mockCar.Expects.One.Method(x => x.Print(null).With(new CarMatcher(car));

I figure it is okay to use either use null or default(Car) along with matchers.

 

i