Rhino Mocks

Recursive Mocks

I have been going through all of the unit tests for Rhino Mocks attempting to get the first “alpha” release ready. One of the sets of unit tests that were failing (miserably) were the “Recursive Mocks.” I struggled with this for a while. I could implement the feature as intended or simply ignore it and change the unit tests.

Not all of us may know what a Recursive Mock looks like and what the feature enables. Let’s take a quick look at an example. First we will look at how the scenario is commonly implemented followed by the Recursive Mock feature.

The scenario is fairly straightforward and common; two interfaces are being mocked where one of the interfaces contains a method which returns the other interface:

public interface IChannel {
  bool IsOpen();
}

public interface IConnection {
  IChannel CreateChannel(string path);
}

The most common way to mock the IsOpen method is as follows:

[Fact]
public void Scenario_Common_Approach() {
  var connection = Repository.Mock<IConnection>();
  var channel = Repository.Mock<IChannel>();

  channel.Stub(x => x.IsOpen())
    .Return(true);

  connection.Stub(x => x.CreateChannel(Arg<string>.Is.Anything))
    .Return(channel);

  // some interesting test here
}  

With the Recursive Mock feature, however, this scenario could be mocked in the following way:

[Fact]
public void Scenario_Recursive_Approach() {
  var connection = Repository.Mock<IConnection>();

  connection.Stub(x => x.CreateChannel(Arg<string>.Is.Anything).IsOpen())
    .Return(true);

  // some interesting test here
}

While this is a contrived example, what we can see from the Recursive Mock approach is that we don’t need to create a mock for IChannel. Rhino Mocks will actually create a mocked object on-the-fly.

Why would anyone ever use a Recursive Mock?

Imagine what would happen if you had three separate “paths” that you wanted to test. For the first path the IsOpen should return true. For the second path IsOpen should return false. For the third path IsOpen should throw an exception.

That would require three separate IChannel mocked objects (and stubs):

[Fact]
public void Three_Path_Monty() {
  var connection = Repository.Mock<IConnection>();
  var channelOk = Repository.Mock<IChannel>();
  var channelFail = Repository.Mock<IChannel>();
  var channelThrow = Repository.Mock<IChannel>();

  connection.Stub(x => x.CreateChannel("path-ok"))
    .Return(channelOk);

  connection.Stub(x => x.CreateChannel("path-fail"))
    .Return(channelFail);

  connection.Stub(x => x.CreateChannel("path-throw"))
    .Return(channelThrow);

  channelOk.Stub(x => x.IsOpen())
    .Return(true);

  channelFail.Stub(x => x.IsOpen())
    .Return(false);

  channelThrow.Stub(x => x.IsOpen())
    .Throws(new Exception("error"));

  // something interesting
}

The Recursive Mock way… much easier to read:

[Fact]
public void Three_Path_Easy() {
  var connection = Repository.Mock<IConnection>();

  connection.Stub(x => x.CreateChannel("path-ok").IsOpen())
    .Return(true);

  connection.Stub(x => x.CreateChannel("path-fail").IsOpen())
    .Return(false);

  connection.Stub(x => x.CreateChannel("path-throw").IsOpen())
    .Throws(new Exception("error"));

  // something interesting
}

The current version of Rhino Mocks supports this well with the Record and Last Call constructs. With these constructs having been removed in the upcoming version, this feature may be more difficult that what it’s worth. At least that’s what I thought… at first.

My biggest concern was with the fact that in the upcoming version an instance of the expectation is created prior to allowing the interceptor to handle the actual method. With the return types from one method to the next in the chain being different than the return type of the calling delegate I was fearful that my dreams of no state and returning “smart” expectations were lost.

As it turns out this was mitigated through the use of the stack. When a expectation is created it is pushed onto a stack belonging to the mocked object. When the interceptor handles the method call it is able to check the mocked object’s stack for the latest expectation. Implementing the Recursive Mock feature came down to creating the “next” expectation on the fly.

There is a little bit of code clean-up required to make the implementation a little easier to read but beyond that… Recursive Mocking has been implemented.

Next up: Property Behavior.

As it stands right now, this is way more trouble than it’s worth.

Standard
Rhino Mocks

Am I Just Getting Lazy?

So I have been working on simplifying the Rhino Mock code base for a little while now and have been making good progress. While I have no empirical data yet, I fully expect this simplified code base to be faster and easier to understand.

It has been really interesting watching some of the core concepts shift from being “in your face” to a more subtle “nudge” as the code is simplified. For instance; generating a Strict mock versus a Dynamic, Stub or Partial mock. There are some very important concepts behind choosing the right “type” but what are they and how are they presented?

This has actually caused confusion in the past… and rightly so. A Strict mock is one where any method call that has not had an expectation set will throw an exception. A Dynamic mock is one where only those methods that have had expectations set are verified. Those methods that have no expectations simply return default values. A Stub mock acts just like a Dynamic mock but does not perform any verifications. A Partial mock… well… gives you the ability to call the original method as long as it isn’t abstract (and is virtual of course).

While this is a greatly simplified overview, it identifies a few problems.

In my mind a Strict mock is a verification concern and not a generation (or creation) decision. When expectations are being verified I should have the option to perform the verification strictly or not. The type of mocked object shouldn’t dictate that choice.

[Test]
public void Strict_Verification() {
  var mock = MockRepository.Mock<IPerson>();
  mock.Expect(x => x.GetName())
    .Return("Mike");

  mock.GetName();
  mock.GetAge();

  mock.VerifyExpectations(VerificationType.Strict);
}

In my mind a Stub mock is an expectation concern rather than a generation decision. Either you are setting up an expectation or you are stubbing out the method.

[Test]
public void Stub_A_Stub() {
  var mock = MockRepository.Mock<IPerson>();
  mock.Stub(x => x.GetName())
    .Return("stub?");

  mock.Expect(x => x.GetAge())
    .Return(1);

  mock.GetName();

  mock.VerifyExpectations();
}

If Stub is removed as a “type” of mock object then we also get the added benefit of eliminating the confusion around when to call Expect and when to call Stub. If both Strict and Stub are removed, does Dynamic make any sense?

The Partial mock is the "most correct” decision that needs to be made when creating a mocked object. A Partial mock is a mixture between a concrete class and a derived proxy class that allows me to choose to execute the base method or “mock it away.” A Partial mocked object, however, should be the only type which would expose the CallOriginalMethod method.

[Test]
public void Partial_Person() {
  var mock = MockRepository.Partial<Person>();
  mock.Stub(x => x.CalculatePayRate(Arg<int>.Is.Anything))
    .CallOriginalMethod();

  var rate = mock.CalculatePayRate(35);

  Assert.AreEqual(11.25, rate);
}

Through simplification of the code Rhino Mocks will now only offer two options to create a mocked object: Mock and Partial. None of the core concepts have been removed but they have been muted a little.

The thing I need to figure out now is whether or not I arrived at this decision because I am too lazy to implement those different “types” or because it makes more sense… maybe a little bit of both.

Standard
.Net, Rhino Mocks

Simplifying the Rhino Mocks Code Base

It has been an interesting last couple of days.

I finished converting all of the existing unit tests from using Record/Replay syntax to the Arrange/Act/Assert (AAA) syntax. Oddly enough this lead to a few extra unit tests that were not previously being executed. These newly discovered unit tests could have been removed due to relevance or performance but for whatever reason, they have been added back. I did find that there were a few (eleven in fact) that were no longer relevant and needed to be “skipped.” They are all passing now so… mission accomplished.

With this done I started turning toward the main code base. And… here we go.

Intercepting the Interceptors

Things started out simple enough; moved similar concerns into a different namespace, removed “generated” files minor code corrections. I then moved onto simple refactoring like reducing nesting and leveraging TryGetValue on a Dictionary. Everything was going well. I then started to tackle the interceptors and invocation actions.

If you didn’t already know, Rhino Mocks (as with many other frameworks) utilizes Castle Windsor to create proxies and intercept method calls (via DynamicProxy). This gives us the ability to create proxies for interfaces, delegates and classes that can then have calls intercepted. Some of the methods, however, are from the base System.Object class which everything in the .Net framework inherits. As it turns out, you can actually configure Castle Windsor to ignore these methods. If any method is ignored, however, they are never called which leads to some interesting issues with this like equality and comparison.

Rhino Mocks current solution for this is to intercept these calls and check to see if the method belongs to System.Object. If the method does belong to System.Object then the method is allowed to proceed. This type of “checking” continues for things like properties and events.

I was a little taken back when I came across this. Not because it was being done but how it was being accomplished. As I started to refactor this code I came to the realization that Castle Windsor supports something very similar through something called the IInterceptorSelector interface. When this interface is implemented it allows you to choose which interceptor should handle the method. By adding an implementation of this interface and a few more interceptors, all of the existing code and constructs can be removed.

One Step Forward, Two Steps Back

It would have been great to stop right there. As you might have guessed; that didn’t happen.

After this minor success I turned my focus on the MethodOptions that are returned when you create an expectation. I decided that since the system knew when a Void method was being called there should be no reason to return MethodOptions with a Return method available. Along the same lines, Return method (when it is available) should be allowed to take a Func to return the value.

Diving into this lead me to understand Record/Replay is much more than just a syntax but is the only way Rhino Mocks currently works. When using the AAA syntax, behind the scenes, Rhino Mocks transition the “state” from Replay to Record and back to Replay. Kind of sounds like a lot of steps doesn’t it? Just a tad.

Rather than perpetuating the current approach, a simpler strategy is underway. This strategy does away with the various “states” and puts the onus on the code creating the expectation. The AAA syntax conforms to this nicely since there is really only one way create a expectation. Based on my estimates, this strategy should reduce the code base by around 30 classes. Clearly there will be additional classes added but will be geared towards usability rather than internal plumbing.

I am planning on having a working code set with a majority of the changes completed within the next few weeks. Some of these modifications can be done in the existing code base in which case I’ll cut a minor release. Should be exciting!

Standard
Rhino Mocks

If you give a Rhino a cookie…

There is a book that I use to read to my daughter titled “If You Give a Mouse a Cookie.” It’s a funny book which takes the reader through a circular pattern of what happens if you give a mouse a cookie. My daughter would often wait till the end of the story to ask what happened next. In my mind this was a clever attempt to have me read the book again (and again). There were sometimes, however, I would re-read the story; especially after a loving “pleeaaassseeee”

As I have been “healing” the existing unit tests, this book came to mind as I begin to see a “circular pattern.” Granted this doesn’t produce anything wrong or exhibit poor code but… I can see where these “circular patterns” have lead to confusion and claims of Rhino Mocks being overly complex.

A good example of this can be found with the Expect and SetupResult utility classes versus the Expect extension method.

The Expect extension method was added as a part of the Arrange Act Assert (AAA) syntax. Since I prefer the AAA syntax, this is the method that I use the most. Let’s take a quick look at an example:

[Fact]
public void Test_One() {
  var mock = MockRepository.GenerateMock<ISomeClass>();

  mock.Expect(x => x.SayHello())
    .Return("Hello World");

  var hello = mock.SayHello();

  Assert.Equal("Hello World", hello);
  mock.VerifyAllExpectations();
}

Unfortunately there is nothing stopping a developer from using one of the other two approaches. The following two examples show how the Expect and SetupResult utility classes are (basically) interchangeable.

[Fact]
public void Test_Two() {
  var mock = MockRepository.GenerateMock<ISomeClass>();

  Expect.Call(mock.SayHello())
    .Return("Hello World");

  var hello = mock.SayHello();

  Assert.Equal("Hello World", hello);
  mock.VerifyAllExpectations();
}

[Fact]
public void Test_Three() {
  var mock = MockRepository.GenerateMock<ISomeClass>();

  SetupResult.For(mock.SayHello())
    .Return("Hello World");

  var hello = mock.SayHello();

  Assert.Equal("Hello World", hello);
  mock.VerifyAllExpectations();
}

What isn’t obvious, however, is that these two tests will fail. The two worlds simply don’t play nice together. It is true that they can co-exist and you could modify the tests above to make them pass but… is it worth it?

In other words, if you give a developer a cookie…

Rhino Mocks will be going on a diet and won’t be offering any more cookies. No matter how lovingly I hear “pleeaaassseeee”

Standard
Rhino Mocks, Unit Testing

Rhino Mocks Unit Tests (let the healing begin)

Over the past few days I have been focusing on “removing” the Record/Replay functionality from Rhino Mocks. I am a little surprised of how easy it was. The first step was to change all of the public methods in the MockRepository class to internal. The second step (and last step) was to add some methods to generate repositories. Granted, this doesn’t actually remove the Record/Replay functionality but it does “hide” it. Clearly taking baby steps.

Attempting to build everything and run the unit tests… not so much. Definitely got the “red” part down.

So I did the only thing that seemed reasonable, exclude every single class from the unit test project. I would have loved to have stopped right there and called it a day but (as with all good unit testers); no “green,” no “go.”

Now I am in the middle of changing every test, one-by-one. It is amazing how many of the tests utilize the Record/Replay style. It actually feels like every single test.

So far, the stats are as follows:

  • Original Passing Tests: 806, Original Skipped Tests: 2
  • Current Passing Tests: 461, Current Skipped Tests: 6

As I modify these tests (attempting to maintain the original intent), I have been noticing some of the constructs simply don’t make sense any more. Things like the BackToRecord and Replay methods as well as the Expect, LastCall, SetupResult and With utility classes. And don’t get me started on OrderedMethodRecorder and UnorderedMethodRecorder.

I am confident that these constructs will find their place in history soon enough. But first… the unit tests must be cured. Then the real slicing can begin.

Standard
.Net, Rhino Mocks

Unwinding Rhino Mocks

Finally, progress!. Sure, the “progress” is 124 build errors but… it’s progress; right?

One of the things that I have been doing is cleaning up the code base by removing projects, assemblies and code that are no longer relevant. I am actually surprised of how much code was never built. It has also been interesting finding artifacts from previous build strategies and repositories. Things like NAnt scripts and merge diff files (from SVN). Even found an old version of NUnit hiding out.

To be honest, this is some of the most fun that I have had in a while. There is nothing better than deleting things!
(Perhaps I need to get out more)

Attempting to update to the latest version of Castle Dynamic Proxy (now in Castle.Core assembly), however, has caused a little problem. About 124 problems to be exact. Armed with my trusty editor (Vim), these issues have been quickly dispatched.

With the build errors fixed there are now nine tests failing (out of 806). Progress indeed. Hopefully these will be corrected tomorrow so I can commit the changes and start digging into some “real” changes.

Standard
Rhino Mocks

Planning the Next Rhino Mock

It has been a week since I have been given the “keys” to the Rhino Mocks framework and it has been an eye opening experience, to say the least. It was great to receive encouragement and interest from so many of you. It has empowered me to do even more while at the same time added a little more pressure to not screw up (let’s see how that works). Not wanting to waste a minute, I cracked my knuckles and dove into the code base. I have been in the code base before but this time there was something different to the way I looked at it… from the perspective of change.

Admittedly there is some hesitation to critique the code base (as some of you may be aware of [grin]). It is clear, however, that the code base has been built upon over time; adding new functionality and features on top of the original implementation. A framework that can survive over time (and versions of the CLR) in this way is impressive. With that being said, it is also an unfortunate reality.

So… on to the plan…

First and foremost, the code base needs to be simplified resulting in a reduced number of extensions and “alternatives.” It is time to pick one: Record/Replay or Arrange/Act/Assert. My preference is with Arrange/Act/Assert (or AAA) as it produces unit tests that are easier to read and comprehend.

This will take some work as the AAA approach is actually built on top of the Record/Replay functionality (which is not surprising given its history). There will need to be an effort in which the Record/Replay is internalized and eventually abstracted away as state machine with key touch points exposed in which the AAA layer interacts with. Baby steps… baby steps…

Secondly, the initial .Net Framework versions to be targeted will be 3.5, 4.0 and 4.5. This is important to note as the existing code contains older constructs to support 2.0 (and 1.1 possibly) as well as preprocessor directives to omit functionality. These older constructs can (and should) be swapped out with newer ones that better target these “initial” .Net Framework versions.

Rather than depending on preprocessor directives, psake can be utilized to target different versions. If you haven’t heard or used psake, I strongly suggest you take a look. It is currently being used to generate the AssemblyInfo.cs files on the fly, run ILMerge and execute unit tests. It can also be leveraged to target different .Net Framework versions to the point where certain projects can be included or excluded from a build. It may even be able to be leveraged to support a Mono build (given a separate code set potentially).

This (initial) plan is somewhat dramatic but important to create a better foundation to build upon. Not wanting to get too far ahead of myself, it is time to internalize Record/Replay…

If you have any feedback or input, let me know here or in the mailing list for Rhino Mocks.

Standard