You’ll often hear proponents of test-driven development claim that unit testing is hard and that it forces them to open up their classes’ hidden logic for them to be testable. That might be true to some degree, but more often in my opinion you’ll find that designing your system to be testable also has the nifty side-effect of separating your logic into .. umm logical chunks… and what I really mean here is that your chunks have a tendency to become orthogonal, which is by far one of the best quality attributes of a system.

BUT that was not what I was going to say, actually – I just wanted to comment on a nifty thing, I recently found out: implementing my own Matcher to use with NMock.

An NMock Matcher is an abstract class, which requires you to implement the following members:

A matcher can be used in the call to With(...) when stubbing or expecting… an example could be setting an expectation that a search function on our user repository will return an empty result… like so:

In the example above, Is is a class containing a static method StringContatining, which returns a matcher of a certain type. Now, when the test runs, and NMock needs to decide if an intercepted function call matches the expectation above, it will iterate though the given matchers, and call their Matches function, passing to it the actual argument as object o.

The matcher returned by StringContaining probably contains an implementation of Matches which looks something like this:

where _substring was probably set in the ctor of the matcher when it was constructed by the StringContaining function.

Now that leads me to my recent problem: I needed to pull out the actual argument given when the expected function call was performed. In my case the argument was a delegate, which I wanted to pull out, and then invoke it a few times with different arguments.

What I did was this:

This allows me to set up an expectation like this:

Now, after the code has been run, I have access to the delegate passed to the file service through snatcher.Object.

If someone knows a cooler way to do this, please do post a comment below. Until then, I will continue to think that it was actually pretty nifty.

Tailoring a custom matcher for NMock

2 thoughts on “Tailoring a custom matcher for NMock

  • 2008-05-30 at 22:27
    Permalink

    Hi,

    I’m a nmock developer and just saw your page. Good information on writing a custom matcher, although you can get your desired behavior already in NMock.

    becomes

    then snatcher.Parameter will return the object. I will look at updating NMock so that this works with generics.

    Reply
  • 2008-06-06 at 08:28
    Permalink

    Hi Richard,

    Funny, I can’t find the CollectAction class in NMock… I can find the following implementations of IAction:
    ResultSynthesizer
    ReturnAction
    ReturnCloneAction
    SetIndexedParameterAction
    SetNamedParameterAction
    ThrowAction

    I am using version 1.0.2313.18049 of NMock2. Is it older than yours?

    Reply

Leave a Reply

Your email address will not be published. Required fields are marked *

%d bloggers like this: