Which one do you use (if you use the listed ones) and what do you love and even hate about it?
I use Rhino Mocks. It's good, but it's got a couple of issues, particularly with threading.
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.
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;
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.
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.
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.
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");
Roy Osherove's Blog has an entry on Choosing a Mock Object Framework.
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).
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.
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.
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.
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.]
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.
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.