<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Rhino Mocks on Meisinger Two</title><link>https://meisinger.github.io/tags/rhino-mocks/</link><description>Recent content in Rhino Mocks on Meisinger Two</description><generator>Hugo</generator><language>en-us</language><lastBuildDate>Sat, 16 Aug 2025 11:49:03 -0400</lastBuildDate><atom:link href="https://meisinger.github.io/tags/rhino-mocks/index.xml" rel="self" type="application/rss+xml"/><item><title>Rhino Mocks Core</title><link>https://meisinger.github.io/post/2025-08-16-rhino-core/</link><pubDate>Sat, 16 Aug 2025 11:49:03 -0400</pubDate><guid>https://meisinger.github.io/post/2025-08-16-rhino-core/</guid><description>&lt;p>I have been itching to get back to working on Rhino Mocks and I finally have a chance to do so.&lt;/p>
&lt;p>The next version of Rhino Mocks will be a complete rewrite moving to dotnet core.&lt;/p>
&lt;p>One thing that I have always had difficulty with is the use of the Castle DynamicProxy library. It has always been a lot of hand waving and magic that I never really understood. I also always felt that it was using a sledgehammer to push in a thumbtack.&lt;/p></description></item><item><title>Rhino Mocks 4.0.0 Alpha Released</title><link>https://meisinger.github.io/post/2014-03-31-rhino-mocks-4-0-0-alpha-released/</link><pubDate>Mon, 31 Mar 2014 00:00:00 +0000</pubDate><guid>https://meisinger.github.io/post/2014-03-31-rhino-mocks-4-0-0-alpha-released/</guid><description>&lt;p>It has been a little longer than expected but the latest version of Rhino Mocks has been released and is available from &lt;a href="https://nuget.org">NuGet&lt;/a>.
You can download the package from here:&lt;/p>
&lt;p>&lt;a href="https://www.nuget.org/packages/RhinoMocks/4.0.0-alpha">RhinoMocks 4.0.0-alpha&lt;/a>&lt;/p>
&lt;p>This is an “alpha” release since there are more than likely going to be a few things that come up.
As a matter of fact, there are two things that I am already thinking about changing.&lt;/p>
&lt;p>One is to be a little more explicit with arranging expectations against properties.
Right now when you arrange an expectation against a property the intent is inferred.
Instead I think it would be better to be explicit by adding &lt;code>ExpectPropertyGet&lt;/code> and &lt;code>ExpectPropertySet&lt;/code>.&lt;/p></description></item><item><title>Rhino Mocks NuGet</title><link>https://meisinger.github.io/post/2014-03-17-rhino-mocks-nuget/</link><pubDate>Mon, 17 Mar 2014 00:00:00 +0000</pubDate><guid>https://meisinger.github.io/post/2014-03-17-rhino-mocks-nuget/</guid><description>&lt;p>From the beginning of my little adventure I had planned on making sure that Rhino Mocks had a consistent NuGet presence.
So it was quite surprising, as I near the end of my first go with revamping Rhino Mocks, that I would get an email about Rhino Mocks package in NuGet.
The previous owner of the Rhino Mocks package (Ka-Wai Lin) contacted me to relinquish his ownership and allow me to take it over.&lt;/p></description></item><item><title>Rhino Mocks Final Stretch–Field Problems</title><link>https://meisinger.github.io/post/2014-03-04-rhino-mocks-final-stretchfield-problems/</link><pubDate>Tue, 04 Mar 2014 00:00:00 +0000</pubDate><guid>https://meisinger.github.io/post/2014-03-04-rhino-mocks-final-stretchfield-problems/</guid><description>&lt;p>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.&lt;/p></description></item><item><title>Rhino Mocks Expectations for Events</title><link>https://meisinger.github.io/post/2013-10-22-rhino-mocks-expectations-for-events/</link><pubDate>Tue, 22 Oct 2013 00:00:00 +0000</pubDate><guid>https://meisinger.github.io/post/2013-10-22-rhino-mocks-expectations-for-events/</guid><description>&lt;p>If one of the features I don’t use very often is the [Property Behavior]({% post_url 2013-09-17-rhino-mocks-property-behavior %}) then it’s safe to say that
I have never (ever) used “events” within Rhino Mocks.
I have seen the &lt;code>Raise&lt;/code> and &lt;code>GetEventRaiser&lt;/code> extension methods in the passed but never used them.&lt;/p>
&lt;p>After working through the Property Behavior feature I decided to tackle handling events.
I found setting up expectations for events to be really easy.
Why? Because there is nothing to them. No really. There is nothing to them at all.
The only thing that you can do with events is validate (or expect) subscribing or unsubscribing from an event.&lt;/p></description></item><item><title>Rhino Mocks Property Behavior</title><link>https://meisinger.github.io/post/2013-09-17-rhino-mocks-property-behavior/</link><pubDate>Tue, 17 Sep 2013 00:00:00 +0000</pubDate><guid>https://meisinger.github.io/post/2013-09-17-rhino-mocks-property-behavior/</guid><description>&lt;p>One feature that I seldom use in Rhino Mocks is the “Property Behavior.”
I remember getting an exception every now and then when I would use a property but never really thought much of it
(like a mindless drone I would change the code and run the unit tests again).&lt;/p>
&lt;p>In fact, I used properties so infrequently in my unit tests, it wasn’t until I started diving deep into the code that I came to realize there are
three “property” based options:&lt;/p></description></item><item><title>Recursive Mocks</title><link>https://meisinger.github.io/post/2013-08-20-recursive-mocks/</link><pubDate>Tue, 20 Aug 2013 00:00:00 +0000</pubDate><guid>https://meisinger.github.io/post/2013-08-20-recursive-mocks/</guid><description>&lt;p>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.&lt;/p>
&lt;p>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.&lt;/p></description></item><item><title>Am I Just Getting Lazy?</title><link>https://meisinger.github.io/post/2013-08-13-am-i-just-getting-lazy/</link><pubDate>Tue, 13 Aug 2013 00:00:00 +0000</pubDate><guid>https://meisinger.github.io/post/2013-08-13-am-i-just-getting-lazy/</guid><description>&lt;p>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.&lt;/p>
&lt;p>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 &lt;strong>Strict&lt;/strong> mock versus a &lt;strong>Dynamic&lt;/strong>, &lt;strong>Stub&lt;/strong> or &lt;strong>Partial&lt;/strong> mock.
There are some very important concepts behind choosing the right “type” but what are they and how are they presented?&lt;/p></description></item><item><title>Simplifying the Rhino Mocks Code Base</title><link>https://meisinger.github.io/post/2013-07-25-simplifying-the-rhino-mocks-code-base/</link><pubDate>Thu, 25 Jul 2013 00:00:00 +0000</pubDate><guid>https://meisinger.github.io/post/2013-07-25-simplifying-the-rhino-mocks-code-base/</guid><description>&lt;p>It has been an interesting last couple of days.&lt;/p>
&lt;p>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.&lt;/p></description></item><item><title>If you give a Rhino a cookie…</title><link>https://meisinger.github.io/post/2013-07-03-if-you-give-a-rhino-a-cookie/</link><pubDate>Wed, 03 Jul 2013 00:00:00 +0000</pubDate><guid>https://meisinger.github.io/post/2013-07-03-if-you-give-a-rhino-a-cookie/</guid><description>&lt;p>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”&lt;/p></description></item><item><title>Rhino Mocks Unit Tests (let the healing begin)</title><link>https://meisinger.github.io/post/2013-06-27-rhino-mocks-unit-tests-let-the-healing-begin/</link><pubDate>Thu, 27 Jun 2013 00:00:00 +0000</pubDate><guid>https://meisinger.github.io/post/2013-06-27-rhino-mocks-unit-tests-let-the-healing-begin/</guid><description>&lt;p>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 &lt;strong>MockRepository&lt;/strong> 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. &lt;em>Clearly taking baby steps.&lt;/em>&lt;/p></description></item><item><title>Unwinding Rhino Mocks</title><link>https://meisinger.github.io/post/2013-06-07-unwinding-rhino-mocks/</link><pubDate>Fri, 07 Jun 2013 00:00:00 +0000</pubDate><guid>https://meisinger.github.io/post/2013-06-07-unwinding-rhino-mocks/</guid><description>&lt;p>Finally, progress!. Sure, the “progress” is 124 build errors but… it’s progress; right?&lt;/p>
&lt;p>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.&lt;/p></description></item><item><title>Planning the Next Rhino Mock</title><link>https://meisinger.github.io/post/2013-05-29-planning-the-next-rhino-mock/</link><pubDate>Wed, 29 May 2013 00:00:00 +0000</pubDate><guid>https://meisinger.github.io/post/2013-05-29-planning-the-next-rhino-mock/</guid><description>&lt;p>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.&lt;/p></description></item><item><title>Rhino Mocks New Home</title><link>https://meisinger.github.io/post/2013-05-20-rhino-mocks-new-home/</link><pubDate>Mon, 20 May 2013 00:00:00 +0000</pubDate><guid>https://meisinger.github.io/post/2013-05-20-rhino-mocks-new-home/</guid><description>&lt;p>I am proud to state that Rhino Mocks has a new home. I must admit that I am feeling a little nervous.
Its not every day that you get take charge of a project like Rhino Mocks.&lt;/p>
&lt;p>There are some plans to modify the code based on the original “4.0” roadmap from a few years ago but the initial
focus will be to create a single location to download the binaries. Once this is established then things like “alpha” and “beta” builds can be done.
I also believe strongly in documenting the features that are currently available.
Perhaps a wiki or website can be created to help out in this area (especially for some of the more complex features).
Along the same line, another primary focus will be to promote the principles behind Rhino Mocks. In other words, answering the “why” versus the “how&amp;quot; questions.&lt;/p></description></item><item><title>State of Rhino Mocks</title><link>https://meisinger.github.io/post/2013-05-16-state-of-rhino-mocks/</link><pubDate>Thu, 16 May 2013 00:00:00 +0000</pubDate><guid>https://meisinger.github.io/post/2013-05-16-state-of-rhino-mocks/</guid><description>&lt;p>&lt;a href="http://http://ayende.com/blog/">Ayende Rahien&lt;/a> (Oren Eini) recently &lt;a href="http://ayende.com/blog/161826/the-state-of-rhino-mocks">posted&lt;/a> about the state of Rhino Mocks.
For those of you who don’t know, Rhino Mocks is a dynamic mock object framework for the .Net platform that Ayende created and developed
which allows developers to “mock away concerns” in unit tests. I remember stumbling across Rhino Mocks around 2006 and ever since that time I have been hooked.
I have tried other mocking frameworks but each time I have always returned to Rhino Mocks.&lt;/p></description></item></channel></rss>