Mocking Generic Method with NMock2 (part2)

Well although this feature has been mentioned on the web it doesn't seen to exist in any version of NMock2 I can find. With a bit of digging I worked out how to implement it myself.

You can download the assembly from NMock2Extensions try it out, or download the source from svn.

Here's an example of using it...

Stub.On(childScope)
      .Method(new GenericMethodMatcher("Get", typeof(IControl)))
      .Will(Return.Value(control));

Expect.Once.On(childScope)
      .Method(new GenericMethodMatcher("Get",typeof(IDocument)))
      .Will(Return.Value(NewMock()));

As you can see, you can Stub or Mock on the same method with different generic types and they are handled differently, as you would expect.

Happy Mocking

NCoverCop trunk... for coverage

If you grab NCoverCop from svn you can check out a couple of improvements.

• Refactoring Allowed.. If you delete tested code that is no longer needed, then this will unfortunately have the side effect of dropping your coverage percentage. NCoverCop allows for this by checking the number of untested lines. If it has not increased then the build is passes as you didn't make things worse.


• Coverage Differences are displayed when a build fails to give you an idea of the lines in the file that have become uncovered, or been added without test.


• sectionOfFilePathToCompareRegex allows you to specify a section of the document paths in the NCoverResults.xml files to ignore when comparing the files. This allows you to compare the build's file with your local one even if your trunk paths differ.

          coverageFile="${ncover.output.filename}"
          minCoveragePercentage="59"
          previousCoverageFile="${ncover.backup.filename}"
          autoUpdate="${environment::get-machine-name() == debug.buildbox.name}"
          sectionOfFilePathToCompareRegex="trunk.*"
     />

E.g. "trunk.*" (as above) will truncate "C:/something/trunk/somedir/file.cs" to "trunk/somedir/file.cs" when comparing with another results file.


Let me know if you find NCoverCop useful.


Note: Big big thanks to VarianInc for allowing me to do some work on NCoverCop on their dime. They have introduced a policy of using opensource code wherever they can, and contributing back to the community.

Varian (Melbourne) are by far the most agile company I have worked for to date. I highly recommend anyone that is keen to be part of a well functioning agile .Net team to get in contact with them. Email me and I'll forward your details if you like.

Tip#3: Extend your mocking framework

Currently I am using NMock2 in my C# development. I have however made a few extensions to allow me to test some edge cases. Due to the clean design of NMock extending it is really easy.

IAction

A normal use of NMock looks like this:

Expect.Once.On(someObject).Method("methodName").WithAnyArguments().Will(Return.Value("value"));

In this statement the 'Return.Value' method returns an object that implements the IAction interface. The job of this object is to perform some action at the point the expectation matches. In this example the effect is to set the return value of the method to a known string.

However... any class implementing the IAction interface can be passed to the 'Will' method, so if you have some special need to execute code at the point the method is matched, then here is a great place to put it.

Here is an example...

[Test]
public void Move_Sleeps_UntilUpdatedWithTrue
{
    Expect.Once.On(sleeper).Method("Sleep").Will(Execute.Delegate(delegate { mono.Update(false); }));
    Expect.Once.On(sleeper).Method("Sleep").Will(Execute.Delegate(delegate { mono.Update(false); }));
    Expect.Once.On(sleeper).Method("Sleep").Will(Execute.Delegate(delegate { mono.Update(true); }));
    mono.Move(120);
}

Here I have used an IAction class that invokes a delegate at the point your expectation is met. In this case I am using it to test a piece of code that repeatedly sleeps (using a sleeper service) until the object is updated with true. I am intercepting the call to sleep and instead taking the opportunity to update the object.

Here is the code that makes that possible.

public class Execute : IAction
{
  public delegate void DelegateAction();
  private readonly DelegateAction action;

  public static IAction Delegate(DelegateAction action)
  {return new Execute(action);}

  private Execute(DelegateAction action)
  {this.action = action;}

  public void Invoke(Invocation invocation)
  {action();}

  public void DescribeTo(TextWriter writer)
  {}
}

So in way of explanation: the invoke method is want gets called when the expectation is met. It just invokes the delegate the 'Execute' object was constructed with. The rest is just static methods to allow you to say Execute.Delegate(...) rather than new Execute(...)

Next post I'll explain how I test firing events using another extension to NMock.

Tip:#1 Testing Events in C#

If you have a class that causes a .Net event to fire. When writing a test for the event, you can add a handler to the event that sets a flag that you then assert on in your code. Using normal delegates means the variable would need to be a class member and get initialized in Setup. Use of anonymous delegates cleans this up nicely.

[Test]
public void TriggerEvent_CausesEventThatFiresToFire()
{
 Customer customer = new Customer("Ben");
 string changedPropertyName = null;

 customer.PropertyChanged += delegate(object sender, PropertyChangedEventArgs args)
   {changedPropertyName = args.PropertyName;};

 customer.Name = "Kate";

 Assert.AreEqual("Kate",changedPropertyName);
}