Rhino Mocks, xUnit

Fun with xUnit Assert Throws and App Domains

I recently decided to update the shared libraries and tools that are used to build and unit test Rhino Mocks.

I updated psake from version 0.22 to version Now I don’t know about you but that is a significant jump in version number. After the update, no problems. I actually find it easier to deal with and have come to the realization that I should revisit the existing tasks.

I then went ahead and update xUnit from version 1.1.0 to version 1.9.2. After the update I had a significant number of build errors. All of the build errors were concerning the Assert.Throws extension method. In the old version this method had an overload that took a “message” as a parameter. In the latest version this overload was removed.

I was very concerned with this breaking change. There were so many unit tests that used this method to verify the thrown exception message matched the expectation. I cracked open the previous version in dotPeek and took a look at the method. And what I saw was rather surprising.

public static T Throws<T>(string userMessage, ThrowsDelegate testCode)
  where T: Exception
  return (T) Throws(typeof(T), testCode);

Clearly the userMessage parameter is not being used.

Now realizing that the “message” parameter was never being used. I changed all of the unit tests and removed the messages being passed. After I fixed the unit tests everything was working perfectly. This has now become a fortunate change of events. This now provides me with the ability to change the exception messages to provide better context and more information.

All was right in the world. Well…

It was an hour after the update that I realized that I only updated the xUnit libraries. I hadn’t updated the executable or console application that actually ran the unit tests. So back to NuGet I went to get the latest (stable) version of the xUnit console application.

This is where things took a turn for the worse. There was one (and only one) unit test that was now failing. I am going to give you the namespace and test class name and let you figure out what the problem was: Rhino.Mocks.Test.Remoting.ContextSwitchTests

Talk about fun.

I will save you the gory (and embarrassing) details on how I corrected the problem. The bottom line is that I had to change the way the unit test was creating the App Domain to match the same way the xUnit was loading the unit test into it’s App Domain.

There’s a lesson in here somewhere but right now… I can’t think of it.

Coming up next is documentation and getting the first 4.0.0 alpha build out on NuGet.

Rhino Mocks, Unit Testing

Rhino Mocks Final Stretch–Field Problems

The final modifications have been made to the Rhino Mocks code base. It has been interesting working through Properties and Events. What was more interesting, however, were the delegates. Previously these were Callback, Do and WhenCalled and allowed you to pass in a delegate, an Action or a Func to modify the execution flow, change the return value or simply call a delegate. Understanding when to use Callback, Do or WhenCalled was confusing to me so I decided to wrap them up a little differently.

Previously, WhenCalled allowed you to execute an Action that took, as a single parameter, a data structure encapsulating the method invocation. Since an Action was being invoked the return value of the expectation could not be changed.

In the current version, WhenCalled has been modified slightly to simply execute an Action. If the arguments of the calling method are desired then the Action will need to have the same signature of the calling method. One thing that I am continuing to work through is the ability to match the arguments with the parameters of the Action (or delegate) without having to specify all of them. It works but not with “out” or “ref” arguments.

The Callback functionality wasn’t something that I used in the past. The exact reason why this functionality was added is also unknown. From the call signature, unit tests and the way it was executed I can only assume that it was used to validate the arguments of the calling method. This feature has not been brought forward. Not that there isn’t a need but with the available argument constraints I don’t understand the need. If the Callback feature is to ever return it will be re-worded to something like ValidateArgs.

“Do” has been replaced with DoInstead and is meant to allow you to replace the return value from the given Func (or delegate). I don’t particularly like the “Do” notion and may change it to “ReturnInstead.” This may seem like something silly to be considering but the names of the extension methods should reflect their intent as much as possible.

In order to provide a similar feature as the original “WhenCalled”, a new method “Intercept” has been added which expects an Action that takes, as a single parameter, a data structure encapsulating the method invocation. Again, not too certain that I like the name of the method. I also question whether having access to the method invocation is necessary or not. Only time will tell.

I have updated the existing unit tests to use these new constructs over the old and they all pass. So while the code and execution remains the same (or similar), the names of the methods and properly expressing their intent may need some more work.

With all of the “major” unit tests now passing, it is on to the Field Problem unit tests. There are only 104 files to go over so hopefully it will go by quickly. I am hoping that all of them can be converted and pass with limited modification. I have an uneasy feeling, however, that some may need to be removed. It will be important to identify and document what get’s removed in order to speak to them, provide justification and alternatives.

As a side note, someone had asked if this code is on GitHub. The current version that I am working on can be found here:


This will get merged into the “master” branch once the Field Problem unit tests have been added (and passing).

Well… back to unit tests…

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.

Unit Testing

Better Unit Testing and TDD

I just got done watching Rob Conery’s latest installment in his Kona series. I have to say that I like the direction that he is going with it and I hope that he continues producing great screen casts.

After watching the video, however, I noticed some of the comments that were made by others and started to get really frustrated over how developers view unit testing and practicing TDD.

I am not saying that I am the end-all-be-all when it comes to unit testing and TDD. Far from it… lord knows that I have worked on projects where I didn’t produce a single unit test and instead relied on firing up a browser and stepping through the application to "test" the code.

I guess the thing that frustrates me the most is when a developer decides to start practicing TDD or they decide that there is enough benefit from writing unit tests only to later throw their hands up in disgust and (understandably) frustration when it is not working the way they thought it would or how some other blogger showed them how easy it was to write unit tests and practice TDD.

It is my belief that most books, articles, screen casts, blog posts, etc… about unit testing and TDD take the wrong approach. Sure, it would be totally awesome if we could all be put on "green field" projects and new code bases where we are starting from scratch. The reality is, however, that most of us are brought on to existing projects and existing code bases where no testing has been done or if it has… it has been abandoned.

So what is a developer to do? The answer is really simple… write unit tests and start practicing TDD.

The one part of Rob’s screen cast that I liked was when he (quickly) covered the unit tests that he wrote for the existing Shopping Cart application. While I wish he would have spent a little more time on it, I think that he really hit on what a developer should be doing when trying to write unit tests and performing TDD on an existing code base.

Start from the Story and Requirements

The point of the matter is that if you start from the story, requirements, or business case then you can start to get a clearer understanding of what it is that needs to be tested and where to start (regardless of if this a green field project or an existing code base).

Some times you might get stuck and not know where to start even after gathering the requirements or reading the stories. This is a clear indication that you don’t know the full story in which case you have a couple of options: 1) assume that you know what is going on or 2) ask. I think where a lot of people get into trouble is when they start assuming things.

Assumptions – How bad Tests start

Let’s watch what happens when you assume (besides the age old saying of making an ass out of you and me).

You receive (or you read) a story which states "the Company [object] must have the ability to add a User [object]" and you go off and write the following code:

public void When_Adding_User_UserCount_Is_1() {
var customer = new Customer();
var user = new User();


Assert.AreEqual(1, customer.UserCount);


After you fix the compile errors, etc… you run the test and it fails since you have not implemented the AddUser method yet. So you then start to implement the method and you assume that you are going to store the User in a collection. You then further assume that you are going to want to retrieve the User so you decide to create a Dictionary. You make another assumption that the Id property from the User will be used as the key for the Dictionary. Remembering that you still have to satisfy the test, you change the UserCount property to return the count from the Dictionary. Then finally… you make one last assumption, the GetUser method. You write and implement the GetUser method to take an Integer and return the User object from the Dictionary. Just to be safe, you write a test to prove that after you add the User, you can get the User from the Company object.

Assumptions – So what went wrong?

So what went wrong here? Everything works and all of your tests pass so… what is the deal?

The assumptions are the deal. First you have assumed that you need to store the User in a collection. Nothing about the story or requirement indicated that this needed to be done. After that assumption comes all of the other decisions that were not warranted. Finally the big nasty assumption that the User will need to be retrieved and the API created to accomplish it.

With all of those assumptions made, you have coded and unit tested yourself and every other developer on your team (present and future) into a corner. Not only is there no need to have a GetUser method at this time but you run the risk of the method becoming "supported" because other developers now use it to get User objects.

What is worst of all is that there is code now available that isn’t backed by a story or requirement.


So back to my original point. Writing unit tests and practicing TDD is not as hard as people make it out to be as long as you follow the stories and requirements and don’t make assumptions.

Perhaps that is wrong to state. Assumptions are fine when you are assuming how something will work like how the Customer object will be reconstituted from a database some where. The details aren’t important but it is safe to assume that there will be some data access method some where in the framework or code that will handle the retrieval of the Customer object for you. Other assumptions that are integration assumptions are also fine since the details have more than likely not been ironed out yet.

Assumptions about the test and the functionality needed for the application, however, are bad