A brand new release of Rhino Mocks, with a twist.

Jeff emailed me a patch yesterday, that enabled the mocking of delegates. This is not something that I would've ever considered, to tell you the truth, but the idea (and the code) were sound, and I can certainly see uses for this. Consider all the possibilities for near-functional programming that .Net 2.0 opens for us, and you'll see what I'm excited about.

Here is an example of using this new functionality:

[Test]
    public void GenericDelegate()
    {
      Action<int> action = mocks.CreateMock<Action<int>>();
      for (int i = 0; i < 10; i++)
      {
        action(i);
      }
      mocks.ReplayAll();
      ForEachFromZeroToNine(action);
      mocks.VerifyAll();
    }
    private void ForEachFromZeroToNine(Action<int> act)
    {
      for (int i = 0; i < 10; i++)
      {
        act(i);
      }
    }

The other big change is removing IDisposable from the MockRepository. This is a breaking change for somet people, but it is a must. The problem is that the #1 problem that we have with new users of Rhino Mocks is exceptions masking. Removing the IDisposable means that it takes a bit longer to setup the mock repository, but I hope it will also encourage the recommended use of putting the setup & verification in the [SetUp] and [TearDown] methods.

Another change that I made was a bug fix for SetupResult not respecting IgnoreParameters(), which drove me crazy for a while. I’ve updated the documentation and the API docs to reflect the changes . As usualy, you can download or get the source.

Yes, I know that I said that I'm not going to post today. But Jeff fixed a problem with Partial Mocks (couldn't call a method that had parameters). It's 0:45AM, and I'm releasing software... I think that I could be arrested for this. :-)

As usual,  you can download it, or access the source directly.

Thanks Jeff, and it really is turning into a daily build project :-D

This time I actually did nothing for this release. Jeff Brown added support for Out & Ref parameters for Dynamic Proxy, and all I had left to do is hit the build button a couple of times and upload the stuff to the server.

This closes the next to last big problem with Rhino Mocks. The very last one has to do with generic methods, which I hope to be able to fix this week.

 You know the drill, you can download it, or access the source directly.

I created an annonated class diagram for Rhino Mocks.

It's quite big, but here is the small version:

I created this using Visual Studio 2005. Click on the image to see the large version.

The diagram describe Rhino Mocks 2.5.2, released yesterday.

Here are a couple of interesting statistics about Rhino Mocks that I pulled from Cuyahoga. For this table, I merged the results of Rhino Mocks for .Net 2.0 and for .Net 1.1. You can see that the distribution of releases is pretty standard, a flurry of releases, pause, a flurry of release, etc. Rhino Mocks 2.4 is the most popular download, it was the version that added .Net 2.0 features.

Rhino Mocks 1.0 was based on EasyMock.Net, I abandoned the code base after it proved to be too hard to maintain and since it used remoting proxies under the cover, which weren't always compatible with the types being mocked.

Okay, this time it is a bona fide bug, a good one. Rhino Mocks didn’t respect ordering if you were using dynamic mocks.

You know the drill, you can download it, or access the source directly.

It has been two days since the last release, and here I thought that I'm not practicing daily builds.

Can someone please tell me why I almost always make Rhino Releases in bunches? The second I make a release, another thing pop up and I have to make another one.

Rhino Mocks 2.5 is barely out the door, and here I've another great feature.

Partial Mocks:

Partial mock is a mock object whose default action is to call the original method. Why is this useful?

It's useful because you may want to test an abstract method, and you don't want to write a class with a default implementation just for the tests. You can even set expectations on the methods that the class implement, so you can use it if you want to test that a method calls another method in the class.

 As usual, you can download it, or access the source directly.

I updated the API documentation

I'm not really sure why, but of late, there has been a lot of traffic in the Rhino Mocks mailing list. Most of it about new features that people requested, and including some really good patches (thanks to Brian and Geert).

Here is a list of the new features:

• You can now move a mock object back to record mode, this allows you to specify the interactions between the object in small steps every time.
• You can now mock internal classes (.Net 2 only, and require your to specify: InternalsVisibleTo)
• Rhino Mocks understand nullables, and act accordingly (before it would treat them as value types, and wouldn't accept/retun null for them).
• Automatic handling of properties - you can now just say that you want a property to behave like a property, and it just work. It doesn't require implementing anything, so you can do that on interfaces as well. It even works with indexed properties.
• Added a Do() handler that allows you to pass a delegate to control what will happen when a method match expectation. In essense, you can now use a delegate to decide what to do when a method is called (chagne the return value, throw, etc).

Bug fixes:

• Rhino Mocks (and Dynamic Proxy) can now handle overloaded indexed properties properly. (try to say that ten times fast).
• Disabled the trace output that was driving some people nuts.

I'm going to update the API documentation and the documentation about it soon.

As usual, you can download it, or access the source directly.

Okay, so I've a new release out (any time I push out a release, I just know that I'll have to have a new one ready in a short time).

So, what is the story here?

Some time ago I added the ability to easily create stub objects and dynamic mocks. So you could do something like this:

This works fine and I use it daily in my current project, but it's a problem where you get cases where you have a property on your mocked object, let's take this code:

Now, what do you need in order to connect the setter and getter in this case? Well, before 2.4.2 you needed to know about the value beforehand, which was not always possible. Here is how you do it on 2.4.2, however:

What do we have here? We create the mock object, and then we setup two calls, one for the property getter and another for the setter (the syntax may be a little weird for the setter, but it's actually the best syntax that we could think of). We tell Rhino that when it get a call to get_Prop, it should just call the original method on the object, and the same for set_Prop. That is a nice way to do it, I think.

Caveats:

• There is no either/or with this, it doesn't attempt to match arguments to see if it should call the original method or not, it just does.
• You can't set repeats or exceptions or return values, any call for this method will go to the original object.
• You can't use it on interfaces or abstract methods, since there isn't a method there to pass it to.

I would like to apologize for anyone who downloaded build 2.4.1, it was broken, the dynamic proxy wasn’t merged properly. I would also like to thank David for reporting the problem. I was offline for the last three days, so I wasn’t aware of it.

It’s fixed now both in the repository and in the site, just re-grab 2.4.1 and it will be fine.