Rhino Mocks pros and cons

[andreister]

Hi, please have a look at my take on pros and cons for Rhino Mocks.

Do you agree/disagree? Anything else you might consider as a pro/con?

Pros:
1. Open source and free.
2. Type safe.
3. Very powerful (mock classes/interfaces, events, etc).
4. Allows both strict and non-strict mocks.

Cons:
1. Poor internal error messages, esspecially comparing to NMock2.
2. A bit cluttering API for constraints - 4 (four!) root classes: Is,
Property, List and Text.
3. Cannot mock non-virtual, non-abstract and static methods, cannot
mock sealed classes and private interfaces.

[Ayende Rahien]

ineline

On Sun, Jan 4, 2009 at 3:09 PM, andreister <andre...@gmail.com> wrote:

Hi, please have a look at my take on pros and cons for Rhino Mocks.

Do you agree/disagree? Anything else you might consider as a pro/con?

Pros:
1. Open source and free.
2. Type safe.
3. Very powerful (mock classes/interfaces, events, etc).
4. Allows both strict and non-strict mocks.

Cons:
1. Poor internal error messages, esspecially comparing to NMock2.

I would argue with that, actually.

 

2. A bit cluttering API for constraints - 4 (four!) root classes: Is,
Property, List and Text.

There is a reason for that, it makes writing constraints more concise and readable.

If you want, you may use the single entry point, Arg<T>...

 

3. Cannot mock non-virtual, non-abstract and static methods, cannot
mock sealed classes and private interfaces.

Yes

 

[Tuna Toksöz]

And the latest being the CLR issue. However, one can use Mono.Cecil library to play with non virtual/static things, which is beyond the scope of RM.


Tuna Toksöz
http://tunatoksoz.com

Typos included to enhance the readers attention!

[mike]

3. Cannot mock non-virtual, non-abstract and static methods, cannot
mock sealed classes and private interfaces.

This could be considered a Pro.

[Tuna Toksöz]

But sometimes you want to mock someone elses class, and abstraction may be an overhead.

Tuna Toksöz
http://tunatoksoz.com

Typos included to enhance the readers attention!

[Shane Courtrille]

Personally if I have a dependency on an external system (someone elses class) that needs to be mocked out I find it's a good idea to abstract it away (wrap it with something I control).  This gives me the ability to mock it out which is very important but even more important is not coupling myself to something I don't have control over.  If there are changes to the external system my wrappers interface may not need to change.  It may just internally need to modify how it uses the external system.  This reduces change in my code to a single place which is always a good thing.

[Steve Guidi]

[A plug for my library, which is also outside the scope of
Rhino.Mocks]

If you're interested in using an abstraction layer for addressing the
statics/non-virtual issue, you may be interested in a library I am
developing that generates the abstraction for you (at development-
time).

Please view http://www.codeplex.com/jolt/Wiki/View.aspx?title=Jolt.Testing.CodeGeneration.Proxy
for more information.

Steve Guidi
http://joltdev.blogspot.com

On Jan 4, 8:23 am, "Tuna Toksöz" <tehl...@gmail.com> wrote:
> And the latest being the CLR issue. However, one can use Mono.Cecil library
> to play with non virtual/static things, which is beyond the scope of RM.
>

> Tuna Toksözhttp://tunatoksoz.com

>
> Typos included to enhance the readers attention!
>
> On Sun, Jan 4, 2009 at 3:21 PM, Ayende Rahien <aye...@ayende.com> wrote:
> > ineline
>

[Isel Fernandez]

I also use wrappers for external dependencies. Maybe if that is too
much overhead (and it is just one time you are going to use it, second
time, consider better the option of a wrapper to keep it in one place)
you could wrap the call inside a method of your class that could be
mocked and at the same time will help to maintain your code
independent of external dependencies.

[ssteinegger]

IMHO it's an important pro that it is just a library - no deployment,
no visual studio plugin, no build tasks etc. Programmers life is
complex enough and I like the simple things.

The only thing I wish RM improves is the API in general. I don't care
about the constraints classes, but some cleanup is needed. There are
four syntaxes: classic, using, fluent and AAA. Everyones code looks
different. It would be better to have only one syntax (AAA), powerful
enough to replace everything else. There are other parts where the API
is larger than necessary.

[Tim Barcz]

Consider backwards compatibility. I have a lot of code written using Record/Replay.  I would not want all of my code to cease to work, just to make a "cleaner" API.

[ssteinegger]

You're right, but it's still a problem new users have to cope with.
It's about pros and cons of RM here.

On 5 Jan., 00:43, "Tim Barcz" <timba...@gmail.com> wrote:
> Consider backwards compatibility. I have a lot of code written using
> Record/Replay.  I would not want all of my code to cease to work, just to
> make a "cleaner" API.
>

[Jonathon Rossi]

You could just mark all the other code obsolete which wouldn't be a breaking change, which would show up crossed out in ReSharper at least (it does something without ReSharper but I can't remember).

--
Jonathon Rossi

[Ayende Rahien]

That is actually a very problematic thing. I got a lot of heat about marking CreateMock as absolute.

[Jonathon Rossi]

Seriously! People whined about something so stupid, it is a exact replacement.

Microsoft marks methods as obsolete from in the .NET framework.

The methods are marked obsolete, however it is still there, I don't see what the problem is. We have heaps of obsolete warnings in code at my work because our product is so big. I take it to mean you shouldn't use this method in new code and if you are reworking code that uses it fix it up to use the new methods.

--
Jonathon Rossi

[Ayende Rahien]

I assure you that if MS would obsolete ToString, people would whine as well.
CreateMock was the main entry point to Rhin Mocks, after all

[ssteinegger]

Changing to StrictMock took me a few minutes with search-replace. It
is of course not always that trivial, but this one was. I actually
expected more issues. I don't understand why people are complaining
about breaking changes, IF they are moderate, clearly documented and
an enhancement to the product. If someone doesn't like any changes in
his very-big-unmaintainable-monster-project, he just can stay on the
old version. There is no real advancement without breaking changes.

On 5 Jan., 11:01, "Ayende Rahien" <aye...@ayende.com> wrote:
> I assure you that if MS would obsolete ToString, people would whine as well.
> CreateMock was the main entry point to Rhin Mocks, after all
>

> On Mon, Jan 5, 2009 at 11:57 AM, Jonathon Rossi <j...@jonorossi.com> wrote:
> > Seriously! People whined about something so stupid, it is a exact
> > replacement.
>
> > Microsoft marks methods as obsolete from in the .NET framework.
>
> > The methods are marked obsolete, however it is still there, I don't see
> > what the problem is. We have heaps of obsolete warnings in code at my work
> > because our product is so big. I take it to mean you shouldn't use this
> > method in new code and if you are reworking code that uses it fix it up to
> > use the new methods.
>
> > On Mon, Jan 5, 2009 at 7:45 PM, Ayende Rahien <aye...@ayende.com> wrote:
>
> >> That is actually a very problematic thing. I got a lot of heat about
> >> marking CreateMock as absolute.
>

> >> On Mon, Jan 5, 2009 at 11:39 AM, Jonathon Rossi <j...@jonorossi.com>wrote:
>
> >>> You could just mark all the other code obsolete which wouldn't be a
> >>> breaking change, which would show up crossed out in ReSharper at least (it
> >>> does something without ReSharper but I can't remember).
>

> >>> On Mon, Jan 5, 2009 at 9:43 AM, Tim Barcz <timba...@gmail.com> wrote:
>
> >>>> Consider backwards compatibility. I have a lot of code written using
> >>>> Record/Replay.  I would not want all of my code to cease to work, just to
> >>>> make a "cleaner" API.
>

[andreister]

Thanks for bringing up more about the pros/cons thing! :)

About classic vs using vs fluent vs AAA - it's a good question.
Defninitely, different approaches make happy different people, but at
some point diversity becomes a muddle.

So, the question is, where to stop.

My initial reaction - why not to create a separate "Rhino Mock AAA"
branch that does *not* support other syntaxes? (although, this
probably would lead to all sorts of marketing issues that Ayende
doesn't want to care about)

[andreister]

No way! :)

The question here is *not* about design and write-testable-
applications mantras. It's about power of the framework.

[Ayende Rahien]

I feel quite strongly that limiting the capabilities of a piece of software is a great way of getting better design.
If you don't allow to do bad things, bad things wouldn't happen.

[andreister]

No no - again, the question is *not* about "better design".

I really understand what you mean, and absolutely agree with what you
say.

But sometimes it's just have some code that you need to mock. Someone
else's code. You don't control it, but you need to mock it - as quick
and as easy as possible.

Framework that allows the less painful way is the most powerful.
That's how I see it.

Otherwise - if you're talking about simplicity - why introduce things
like recursive mocks and "accessing the method arguments directly"
feature? It's way too powerful for most of cases. Mostly people just
don't need those things. They are misused to create fragile tests
tightly coupled with implementation.

So what - sounds like "limiting the capabilities of a piece of
software" is two-folded.

Not surprisingly.

That's why pros/cons is such a hot topic :))

On Jan 5, 12:54 pm, "Ayende Rahien" <aye...@ayende.com> wrote:
> I feel quite strongly that limiting the capabilities of a piece of software
> is a great way of getting better design.
> If you don't allow to do bad things, bad things wouldn't happen.
>

[Ayende Rahien]

On Mon, Jan 5, 2009 at 4:01 PM, andreister <andre...@gmail.com> wrote:

Otherwise - if you're talking about simplicity - why introduce things
like recursive mocks and "accessing the method arguments directly"
feature? It's way too powerful for most of cases. Mostly people just
don't need those things. They are misused to create fragile tests
tightly coupled with implementation.

Because I need them.
 

[ssteinegger]

Power and complexity is not always proportional. It's the art of every
kind of interface (API, UI, etc.) to provide the maximum of power with
a minimum of complexity. Therefore I don't like the same thing in many
ways, it's additional complexity WITHOUT additional power. I rather
cope with a poor interface ("not as I had done it") and learn to
accept it as having to choose from many interfaces for every taste.

On 5 Jan., 15:10, "Ayende Rahien" <aye...@ayende.com> wrote:

[Ayende Rahien]

You are missing one crucial piece.
I am the user that Rhino Mocks need to make happy.

[ssteinegger]

But you aren't using more then one syntax at the same time, are you?

In this case, there is another way to clean up the interface a bit.
Instead of make whole classes obsolete, you could move them into a
"Legacy" namespace (or "Compatibility34" or whatever). This makes it
available without warnings but also makes it invisible for new users.
Of course, there should be no reason to use this namespace except for
legacy code.

By the way, four different syntaxes to choose from could also be taken
for a pro. Just a matter of taste.

On 6 Jan., 10:54, "Ayende Rahien" <aye...@ayende.com> wrote:
> You are missing one crucial piece.
> I am the user that Rhino Mocks need to make happy.
>

[Shane Courtrille]

Once you have a few thousand tests going back and upgrading all the old ones to the new AA syntax is pretty much not going to happen (even though it probably should).  So actually yeah I've seen code bases that use multiple syntaxes.  In fact I've seen one that uses all 3 (DynamicMock, Record/Replay, AAA).

[Jonathon Rossi]

How do you move methods from the MockRepository into a legacy namespace?

You could conditional compile RM. Just throw a #if BACK_COMPAT around the old stuff. New users should use the non-compat release. However, that means maintaining 2 releases, and dealing with the bugs and pain caused by conditional code.

--
Jonathon Rossi

[Tim Barcz]

"Even though it probably should" -- why?

[Shane Courtrille]

Consistency is something I consider very important.  I'd like to be able to look through the tests in a code base and not have to constantly adjust how I need to read them.  Rhino Syntax is one example.. another is testing styles which usually change over time as people learn more (A big example of this is switching from Method_WhenThisHappens_ShouldDoThis test naming to full BDD styled tests). 

So in a perfect world I'd like to see all tests done in the same style but in practice I don't know how practical that is for a long haul project.

[Tim Barcz]

Do you go back through all of you working code and rename variable to use "var"?

I see this as a thing that I would *like* to do as well, but from a value to the customer organization standpoint this falls very low on the list.

[Shane Courtrille]

I wouldn't but once again I probably should :) 

And I agree with you completely.  I would *like* to do it but I'm not getting paid to do it (unless I'm somewhere working on something in which case "Leave it better then it was when you got there" applies)

[Ayende Rahien]

The AAA syntax doesn't scale to the more complex scenarios.
Ordered, partials, etc.

[Ayende Rahien]

That puts more burden on me. I am having to deal with four separate releases of Rhino Mocks right now, that is more than enough

[andreister]

>switching from Method_WhenThisHappens_ShouldDoThis test naming to full BDD styled tests

Shane could you please elaborate more on that?

On Jan 7, 3:54 pm, "Shane Courtrille" <shanecourtri...@gmail.com>
wrote:

> Consistency is something I consider very important.  I'd like to be able to
> look through the tests in a code base and not have to constantly adjust how
> I need to read them.  Rhino Syntax is one example.. another is testing
> styles which usually change over time as people learn more (A big example of
> this is switching from Method_WhenThisHappens_ShouldDoThis test naming to
> full BDD styled tests).
>
> So in a perfect world I'd like to see all tests done in the same style but
> in practice I don't know how practical that is for a long haul project.
>

> On Wed, Jan 7, 2009 at 7:45 AM, Tim Barcz <timba...@gmail.com> wrote:
> > "Even though it probably should" -- why?
>
> > On Wed, Jan 7, 2009 at 8:25 AM, Shane Courtrille <
> > shanecourtri...@gmail.com> wrote:
>
> >> Once you have a few thousand tests going back and upgrading all the old
> >> ones to the new AA syntax is pretty much not going to happen (even though it
> >> probably should).  So actually yeah I've seen code bases that use multiple
> >> syntaxes.  In fact I've seen one that uses all 3 (DynamicMock,
> >> Record/Replay, AAA).
>

[andreister]

Hmm Ayende do you mean that four releases are:
- RM for .net 3.5 with Castle assmeblies
- RM for .net 3.5 without Castle assmeblies
- RM for .net 3.0
- RM for .net 2.0

Right?

On Jan 7, 8:44 pm, "Ayende Rahien" <aye...@ayende.com> wrote:
> That puts more burden on me. I am having to deal with four separate releases
> of Rhino Mocks right now, that is more than enough
>

> On Wed, Jan 7, 2009 at 4:38 PM, Jonathon Rossi <j...@jonorossi.com> wrote:
> > How do you move methods from the MockRepository into a legacy namespace?
>
> > You could conditional compile RM. Just throw a #if BACK_COMPAT around the
> > old stuff. New users should use the non-compat release. However, that means
> > maintaining 2 releases, and dealing with the bugs and pain caused by
> > conditional code.
>

[Ayende Rahien]

yes

[mike]

Hi Oren,

Are there any plans to make a Silverlight release? Would it depend
only on having a silverlight compiled dynamic proxy? Have you thought
about it?

Thank you
Mike

[Ayende Rahien]

Yes, and yes.
That already exists, but I don't have the time to do it.
A patch for that would be very welcome.

[mike]

I've been considering stripping the code from DynProxy that is needed
starting at the interceptor and following the compiler. Would that
work?

Cheers

[mike]

ohh sorry i didn't understood ... u meant there's a dyn proxy already :) cool

[Ayende Rahien]

This work was already done