views:

7110

answers:

18

Which one do you use (if you use the listed ones) and what do you love and even hate about it?

+3  A: 

I use Rhino Mocks. It's good, but it's got a couple of issues, particularly with threading.

McKay
A: 

I don't. When unit testing, I prefer to test the real code and not just some imaginary scaffolding.

If I really, really need to mock something out, then I use conditional compilation. Just wrap a #If around each version of the class and away you go.

EDIT in response to questions:

How do you handle hitting external depenecies like the DB or mail servers?

I have actual, real-life DB and mail servers specifically configured for testing. In the case of mail, it is setup so that it cannot send mail to external servers.

How do you recreate bugs or get dependencies into sates to isolate your tests?!

By recreating the situation in a test database.

My tests don't run in isolation, they run against copies of the real-world data that I'm actually dealing with. I have no interest in testing against fairy-tale data.

Jonathan Allen
That sounds light a nightmare to maintain! How do you handle hitting external depenecies like the DB or mail servers? How do you recreate bugs or get dependencies into sates to isolate your tests?!
Chris Canal
You are not unit testing, you're doing integration testing.
Corin
-1 - I've had to clean up after people who write code like this.
Sohnee
Do you have 20 monkeys that "test the real thing" every time you deploy to ensure every "real test" passes?Who said testing uses fairy tale data?How do you assure in every release that the bug that was fixed one year ago, hasn't been reintroduced? more monkeys doing "real tests"?O.M.G.....
graffic
I am sorry but this is really misleading. How will you test real code if real code is calling Web service that get paid for each call?And to advocate using conditional compilation instead... Come on, not again!
Vagif Abilov
@Vagif. In that case I would create my own mockup of the web service. There would be no Mock objects inside the application itself, from its perspective the only thing that changes was the URL.
Jonathan Allen
+5  A: 

I've used Rhino and MOQ, but my preference is Rhino. I started usuing MOQ because of the nice 3.5 expressions, but once Rhino 3.5 dropped, I moved back. I'm really not keen on having to use:

Mock<IWhatEver> mock;

and

mock.Object;
Chris Canal
+6  A: 

Coming from Java I tried a few of the .NET framworks (listed above) and eventually settled on Moq. It is just so straight forward and intuitive. I found myself dissatisfied with the Java frameworks I was using after experiencing Moq. EasyMock and JMock both have the record / playback style and it does not make as much sense to me.

Tony Eichelberger
+5  A: 

We use TypeMock. I really like the NaturalMocks concept which allows for absolutely straight forward construction of test cases. It is like it is named: Natural.

JRoppert
+7  A: 

At work we use TypeMock, but on my personal projects I use Moq - I try to minimize the amount of mocking I do so my tests aren't highly coupled to my design, and Moq fits in nicely with this scenario - simple one liners here and there for mocked behavior. When I reach for a mocking framework I first think to myself whether or not I'd be better served by using a fake or a spy first.

matt
+11  A: 

I love MOQ. It is super easy and the syntax just flows. It doesn't support method ordering, but that doesn't concern me too much.

+16  A: 

We had been using NMock but are switching to MOQ for newer development.

I personally prefer the style of MOQ to NMock, plus the guys writing the MVC ASP.NET code are using MOQ.

NMock:

Mockery mocks = new Mockery();
var mockDataLayer = mocks.NewMock<IDataContext>();
Expect.Once.On(mockDataLayer).Method("ReadAll").Will(Return.Value("9"));

MOQ:

var mock = new Mock<IDataContext>();
mock.Expect(x => x.ReadAll()).Returns("9");
ben
<rant>I can't stand such a property/extension methods/syntax abuse. That thing has more meaning in english than in C#, and that's NOT a good thing, IMHO. Why would a class named "Return" have a method "Value"? This makes no sense...</rant> anyways, I hope the framework's good :)
Trillian
Trillian, I know what you mean. As I think about it more, though, I figure we usually have different expectations from our test code than from our production code. I can overlook the bizarre conventions in my test project if it makes unit tests easier to write and analyze.
StriplingWarrior
+10  A: 

Roy Osherove's Blog has an entry on Choosing a Mock Object Framework.

Mark Cidade
Thanks for the link, it was helpful!
itsmatt
Note that the article is a bit old (April 26, 2007), and it contains a lot of outdated information. Like "No need to use strings for method names like in RhinoMocks". Moq is not included, since it wasn't created at that time. It was also written before the Arrange, Act, Assert syntax became popular.
BengtBe
+3  A: 

Is this a duplication of what c# mocking framework to use?

Ngu Soon Hui
It is indeed similar, but I wanted to focus on just the ones I listed and also know what people hate about the one they chose.
Troy DeMonbreun
+4  A: 

We use Rhino Mocks in our large enterprise project. They are straight forward and very powerful. The syntax had some inelegance due to .NET 2.0 limitations. The new version 3.5 fixes that by using .NET 3.5 features (and many other great new features).

Stefan Steinegger
+5  A: 

I use Moq because I like find the fluent interface an use of lambda expressions to be really clean. However I have not used any other mocking frameworks so my opinion is a bit naive.

Thedric Walker
+1 for the Why and the Disclaimer
Umar Farooq Khawaja
+1  A: 

Hi,

I thought I'd share my insights with you.

We have a legacy system with a large heirarchy tree (it could take 50 or more objects to create an object)...

Rhino Mocks bombed on creating our object, and TypeMocks actually works.

So, if you are planning on implementing unit tests on Legacy code, I would definately stay away from Rhino. I know it's free and all, but you will be severly limiting yourself.

+1  A: 

For my home development I use Rhino mock - its free :-)

At my company we use Typemock Isolator cuase' we need to test static methods, sealed classes and sometimes legacy code

+2  A: 

Might be of interest to those who want to make their own opinion: there's mocking-frameworks-compare open source project that compares syntaxes and performance of different mocking frameworks.

andreister
+4  A: 

I'm a big fan of Typemock Isolator and use it both for my personal/open source projects and for work. The big benefit I get is the ability to test all of the bits that interface with sealed/static/otherwise locked-down members of the .NET framework and legacy code.

For example, I interface a lot with old/legacy code that wasn't remotely written with testability in mind. You run into stuff like object constructors that try to connect to databases. Being able to test my code that interfaces with this stuff is great; being able to increase test coverage on that legacy code - without having to rewrite it and potentially introduce new defects - is invaluable.

Another example: web apps. Even using ASP.NET MVC, you don't entirely escape having to interface with the ASP.NET pipeline objects (HttpApplication, HttpContext, etc.). Granted, in many places they've added abstractions around them, but your HttpModules and such don't get that, nor do your custom handlers. That interface code, thin though it may be, still warrants testing, and that's where Isolator comes in handy.

Ever tried to unit test a Visual Studio add-in? Even one written on top of something like CodeRush/Refactor? That's prime Isolator territory, too.

[Disclaimer: I've been named a "Typemock Expert" and am an active member of the Typemock community. I definitely have a bias, but I don't think it's without solid reason behind it.]

Travis Illig
A: 

Don't like TypeMock especially the way they over promote their feature or even advocate abusing. RhinoMock and Moq works well for me. As long as you have a decent design, you should have no problem even interfacing with legacy code.

Kenneth Xu
TypeMock website marketing aside, if you are dealing with sealed classes, etc. that you don't control and can't avoid, then it is great to have a tool such as TypeMock.
Troy DeMonbreun
There are many different ways to deal with sealed classes. One way is adapter pattern. Also MVP pattern helps to deal with poorly designed View framework. When my view is passive enough, I can afford not to test it. In almost all the cases when somebody come to me with a need of mocking a sealed class, it was solved by a better design, resulting in cleaner code that is easier to understand, maintain and test. To me, using TypeMock=="Open the door to design flaw"
Kenneth Xu
Regarding "solved by a better design", again, as I point out if you don't control the code (e.g.: you don't have the source code, you can't convince the creator to change design), then you are very limited. Also, I am not speaking of just View frameworks, I am speaking of all types of code. Regarding the Adapter pattern, it can work in some cases, but can be heavy when all you want to do is add tests to legacy or sealed code. Since TypeMock doesn't create design flaws, Programmers create design flaws, it can also be argued that Visual Studio=="Open the door to design flaw". :-)
Troy DeMonbreun
+8  A: 

I started with Rhino Mocks, but found it frustrating. Prior to v3.5, the record/replay syntax felt like an imposition. The newer AAA syntax (Arrange, Act, Assert) is much nicer, but changing a stubbed return value later is still tricky (or was the last time I used Rhino Mocks).

I switched to Moq and have not regretted it. I converted over all the tests that were using Rhino without too much difficulty. Its philosophy is more in line with "classic" TDD (emphasis on stubs), and I like that. Moq's documentation is significantly better than Rhino's (or was when last I looked). More importantly, it feels more intuitive; I don't have to consult the documentation as much.

If you don't need to target .NET 2.0 (in your unit tests - deployed code can still target 2.0), I'd strongly recommend taking a long look at Moq.

TrueWill