Mocking Frameworks Compare
andreister
set of tests written against Moq, NMock2, Rhino Mocks and Typemock
Isolator - so that people can easily compare the frameworks and make
an informed decision when picking one up.
Here it goes: http://code.google.com/p/mocking-frameworks-compare/
Any response and/or ideas are appreciated.
(TypeMock tests are not finished because the trial version of Isolator
had expired and I haven't got their Free License for Open Source
Projects - yet)
Brian J. Cardiff
gerry_lowry (alliston ontario canada)
written against Moq, NMock2, Rhino Mocks and TypemockIsolator"?
To me, "unified" is like one size fits all ... how is that possible when
the various mocking frameworks have varying syntax and different underlying
frameworks, e.g., AFAIK, MoQ depends on xUnit.
{http://www.clariusconsulting.net/blogs/kzu/archive/2008/04/22/MoQnowusesxUnitforitsunittests.aspx}
Please explain what you mean by "unified".
Thank you.
regards .... gerry (lowry)
Daniel Cazzulino
Can be useful for learning and comparing, but also for people migrating from one to the other.
Moq *tests* are written for xUnit. That doesn't mean that you cannot use Moq with any test framework you like. It has NO dependency whatesoever on xUnit.
/kzu
--
Daniel Cazzulino | Developer Lead | XML MVP | Clarius Consulting | +1 425.329.3471
gerry_lowry (alliston ontario canada)
You wrote in part "Moq *tests* are written for xUnit.
That doesn't mean that you cannot use Moq with any test framework you like.
It has NO dependency whatesoever on xUnit."
(a) so to use MoQ, does that mean the xUnit assembly is not required?
{I do not understand "Moq *tests* are written for xUnit".}
(b) what would I have to do to use MoQ with NUnit for example? ... for MSTest?
(c) if MoQ "has NO dependency whatesoever on xUnit", then what is the purpose of your article
{http://www.clariusconsulting.net/blogs/kzu/archive/2008/04/22/MoQnowusesxUnitforitsunittests.aspx}
"MoQ now uses xUnit for its unit tests"?
Please explain.
Thank you.
Regards,
Gerry (Lowry)
Lucas Meijer
During the development of Moq itself, unit tests have been written to make sure Moq does what it is supposed to do. Since a unit testing tool must be picked to do this, Daniel picked what he apparently liked best: xUnit.
The only connection between Moq and xUnit is that the unit tests that verify if Moq itself works correctly are written in xunit. The tests you write for your software can be done with any unit testing tool you want.
Bye, Lucas
Daniel Cazzulino
Bottom-line: Moq.dll does not depend on anything other than .NET 3.5.
Pick your testing tool, and use Moq to create the mocks for those tests.
gerry_lowry (alliston ontario canada)
that I falsely perceived a non-existent dependency between MoQ and xUnit.
I appreciate both of you for taking the time to explain this. Finally andreister's project
makes sense to me. Also, it's wonderful to be able to use MoQ with many
testing tools since many of us are often micro-managed by others as to what
tools and paradigms we get to use.
regards / gerry (lowry)
P.S.: the more I learn, the more I seem to need to learn;
when it finally all clicks, my head will likely explode.
andreister
verbose in Moq, and custom matchers really, really help out!
Will update the code soon.
On Feb 10, 2:28 pm, "Brian J. Cardiff" <bcard...@gmail.com> wrote:
> On Moq BrainTests.cs you could verify that the iron is hot defining your own
> matchers. It seems that is what you are trying to do.
andreister
quite verbose with Moq, so custom matchers really, really rock!
Will update the source code soon.
> matchers. It seems that is what you are trying to do.
andreister
available: thus, readability, maintainability, learning curve,
specifics and similarities of the frameworks become evident.
Hopefully.
In general, the purpose is three-fold:
1. When newbies decide to use a mocking framework, their opinion is
often influenced ONLY by "public opinion". This project would help
them to dig (and that's why I added source code of Moq, RM and
NMock2).
2. When um, more advanced users start talking about which mocking
framework is "better", sometimes they garble a bit :) This project
could act as a common ground.
3. As Daniel mentions below, it could be useful for people who want to
migrate from one framework to another.
On Feb 10, 5:51 pm, "gerry_lowry \(alliston ontario canada\)"
> Hi andreister ~~ what do you mean by "a unified set of tests
> written against Moq, NMock2, Rhino Mocks and TypemockIsolator"?
>
> To me, "unified" is like one size fits all ... how is that possible when
> the various mocking frameworks have varying syntax and different underlying
> frameworks, e.g., AFAIK, MoQ depends on xUnit.
gerry_lowry (alliston ontario canada)
-----------
I'm newborn with regards to unit testing, mocking, et cetera.
My background in assembler, PL/I, et cetera is of relatively little use.
Therefore, I'm not yet fully qualified to validate the worthiness of my ideas as written herein.
-----------------------------------------------------------------------------------------------
andreister, thank you for clarifying. Now that I better understand your goal,
I find your intentions quite exciting. This is something definitely required for mocking.
Especially for beginning programmers like myself. (I began in 1967).
http://code.google.com/p/mocking-frameworks-compare/
Likewise, I think it's equally required for other related areas. Examples:
unit testing: xUnit, NUnit, MSTest, et cetera
http://www.codeplex.com/xunit/Wiki/View.aspx?title=Comparisons&referringTitle=Home
related: WatiN
tools: Fiddler2
built-in, add-in, and stand-alone test runners: TestDriven.Net, NUnit GUI, et cetera
Additionally, for various paradigms such as simple unit testing versus TDD.
One challenge will be to keep current and historical at the same time.
The current part is more obvious as a necessity.
The historical part is required because one may be required to maintain
legacy mocking code "as is" and/or be empowered to refactor it
to either a later version of the same mocking framework or to refactor
it into a different mocking framework and/or mocking paradigm,
perhaps even into frameworks and/or paradigms that get created in the future.
Source Languages
-------------------
Personally, I wish Visual Basic would disappear.
In reality, that's not something that's going to happen soon.
Ideally, all examples, to the extent possible, need to be given in both cs and vb, imho.
Put another way, I hope that the "Mocking Frameworks Compare" project is intended
as much for novices like myself as it is for gurus like others on this mailing list.
Structuring "Mocking Frameworks Compare"
------------------------------------------------
I think some master index is definitely necessary.
See http://mocking-frameworks-compare.googlecode.com/files/mfcompare-1.0.zip
Documentation as a road map is essential. Here's a rough idea of one possible approach:
Patterns mocked .............................
xxxxxxxxxxxxxx
Framework Version Filename/Path
Moq 3.0.112.1 asasdf.cs / ccccbb
asasdf.vb / vvvvbb
Moq. 2.6.1014.1 asasdf.cs / ccccaa
NMock2 1.2.3262 et cetera
Rhino Mocks 3.5.0.1337
Isolator 5.1.2.0
yyyyyyyyyyyyyy ... et cetera
TIMTOWTDI
----------------
As some Perl programmers say, "There Is More Than One Way To Do It".
Thus contributors should be encouraged to show their own particular
styles and methods and preferably to annotate the pros and cons of each.
--
I do hope that you find these suggestions useful and I look forward to the
unfolding of the "Mocking Frameworks Compare" project.
Thank you.
Regards,
Gerry (Lowry)
----- Original Message -----
From: "andreister" <andre...@gmail.com>
To: "Moq Discussions" <moq...@googlegroups.com>
Sent: Wednesday, February 11, 2009 9:58 AM
Subject: [Moq] Re: Mocking Frameworks Compare
andreister
Not sure I'd like to add historical (read: obsolete) paradigms to the
project, since I'm afraid this would make the project less clear. The
main purpose is to teach newbies how to write CORRECT mocking code,
right off the bat. Legacy tricks would just confuse people.
Your another suggestion about going beyond C# is VERY interesting -
however, I'm not that strong in other languages to make that part. If
anyone would volunteer for porting the code to VB, it would be great.
Likewise, Cobol.NET or L# or anything else from this list -
http://www.dotnetpowered.com/languages.aspx - is highly welcome! :)
The point is that, if possible, every single sample should be covered
in every mocking framework in the MOST SIMILAR WAY, to ease
comparison.
Thanks,
Andrew
On Feb 12, 6:54 pm, "gerry_lowry \(alliston ontario canada\)"
> Disclaimer
> -----------
> I'm newborn with regards to unit testing, mocking, et cetera.
> My background in assembler, PL/I, et cetera is of relatively little use.
> Therefore, I'm not yet fully qualified to validate the worthiness of my ideas as written herein.
> -----------------------------------------------------------------------------------------------
>
> andreister, thank you for clarifying. Now that I better understand your goal,
> I find your intentions quite exciting. This is something definitely required for mocking.
> Especially for beginning programmers like myself. (I began in 1967).
> http://code.google.com/p/mocking-frameworks-compare/
>
> Likewise, I think it's equally required for other related areas. Examples:
>
> unit testing: xUnit, NUnit, MSTest, et cetera
> related: WatiN
>
> tools: Fiddler2
>
> built-in, add-in, and stand-alone test runners: TestDriven.Net, NUnit GUI, et cetera
>
> Additionally, for various paradigms such as simple unit testing versus TDD.
>
> One challenge will be to keep current and historical at the same time.
>
> The current part is more obvious as a necessity.
>
> The historical part is required because one may be required to maintain
> legacy mocking code "as is" and/or be empowered to refactor it
> to either a later version of the same mocking framework or to refactor
> it into a different mocking framework and/or mocking paradigm,
> perhaps even into frameworks and/or paradigms that get created in the future.
>
> Source Languages
> -------------------
> Personally, I wish Visual Basic would disappear.
> In reality, that's not something that's going to happen soon.
>
> Ideally, all examples, to the extent possible, need to be given in both cs and vb, imho.
>
> Put another way, I hope that the "Mocking Frameworks Compare" project is intended
> as much for novices like myself as it is for gurus like others on this mailing list.
>
> Structuring "Mocking Frameworks Compare"
> ------------------------------------------------
> I think some master index is definitely necessary.
gerry_lowry (alliston ontario canada)
adding legacy information now. I'm also not discouraging anyone
who might want to do that with the hope that they will clearly identify the versions.
It's therefore probably a good policy to encourage contributors
to identify the versions used as part of their submissions.
I was thinking more along the lines of not deleting information
as it becomes out of date because maintenance programmers
will possibly be able to put such information to good use.
Also, I was thinking about evolving frameworks since there's
likely to be a transitional phase. Experts like Daniel and yourself
might create early examples of "this is the new way for version X".
Gerry
----- Original Message -----
From: "andreister" <andre...@gmail.com>
Sent: Monday, February 16, 2009 3:21 AM
Hi Gerry, thanks a lot for your suggestions.
Not sure I'd like to add historical (read: obsolete) paradigms to the
project, since I'm afraid this would make the project less clear. The
main purpose is to teach newbies how to write CORRECT mocking code,
right off the bat. Legacy tricks would just confuse people.
Your other suggestion about going beyond C# is VERY interesting -