
.NET mocking frameworks, a comparison - eljbutler
http://www.codetuple.com/articles/unit-testing/rG8NM9372kj/mocking-frameworks-a-comparison-aspnet
======
radicalbyte
Terrible. It's just a list. No examples, no feature comparison, no analysis.

After reading this article, did you know that FakeItEasy is very slow, so is
unsuitable for fuzz testing? Or that NSubstitute can't mock statics, but
Microsoft Moles (absent from this list) can?

I do, because I had a developer in my team do that investigation before we
decided to standardise our unit testing stack.

~~~
rjblackman
what did you end up going with and why?

~~~
radicalbyte
NSubstitute, the team found it easy to use (readable) and it is extremely
fast.

I can't review the decision yet because we were been forced to cut our
investment in unit testing, instead focusing on Selenium tests (sigh,
"management" should know better).

------
skrebbel
I once got so frustrated with the horribly arcane syntax of all .NET mocking
libraries that I made my own, FakeThat[0]. It's unoptimized and not very full
featured, but it's _very_ easy to use.

The idea is that you don't need to learn yet another domain specific language
just to do some assertions on mock call history. So I expose it all as plain
old C# data, LINQ'able and all that, which means you can just use the
assertion library of choice instead of weird mock-library-specific "verify"
methods. The API gets you great autocomplete in IDEs because of static typing,
so you discover the API just by starting to type.

Intellisense-driven discoverability of APIs is one of the great USPs of C# and
Java programming (compared to most other popular languages), and IMO it's a
shame that more TDD related libraries don't make good use of it.

It's not under active development but I'd be willing to take it up again if
there's interest. Would love some HN feedback!

[0]
[https://github.com/eteeselink/fakethat](https://github.com/eteeselink/fakethat)

~~~
keithly
USP = Unique Selling Proposition For anyone who wonders what USP means (like I
did).

------
adamconroy
When people (such as this author) talk about mocks, are they talking about
mocking and testing behavior or just simply fakes / doubles?

My understanding of mocking by example is: you have a class you want to test,
and that class has a dependency on lets say a Mail class that has a SendMail()
method. You mock the Mail class and assert that SendMail() was called as per
your specification.

Given that definition of mocking, I personally don't like mocking. I prefer to
test state not behavior, although I can see in some scenarios behavior is more
important.

~~~
dvcc
Oh god mocks/fakes/doubles. The best answer to that probably comes from The
Art of Unit Testing as explained on SO:
[http://stackoverflow.com/a/33333064/2136440](http://stackoverflow.com/a/33333064/2136440).

In short yea, you're right.

~~~
gokhan
Osherove's example on SO thread on mocks being troublemakers does not apply
what adamconroy is asking, though.

Mocking libraries create dummy objects. They can't reproduce inner workings of
mocked object unless you set it up to behave like that, which means you should
duplicate the original which is pointless. You set up the mock to listen on
it's entry points (and to return some predetermined answer), give it to your
code under test, and expect the mock to be called in a certain way. This is
testing the entry point of the mocked object, not it's internal workings. This
way, you're expecting the code under test to behave according to a definition,
so you're still testing your code, the way it's calling some other object
gives you insights of your code's inner workings.

~~~
dvcc
I was just saying his idea of what differentiates a mock from a fake was
right!

------
ded3d
I've seen .NET projects with massive amounts of complexity because of DI
introduced to support mocking. It's become a cult/fetish in some parts. There
has to be a better solution.

~~~
JackMorgan
Check out SimpleMock, it attempts to undo DI damage while still allowing for
testing. [http://deliberate-software.com/simplemock-unit-test-
mocking/](http://deliberate-software.com/simplemock-unit-test-mocking/)

------
dvcc
There is something other than Moq? I'm only partially joking... But I really
haven't found a reason to switch from it. I find the syntax easy enough and if
I ever come up on a problem the question was probably already asked.

~~~
tigershark
There are too many unnecessary lambdas involved when using it as far as I
remember. NSubstitute syntax feels more natural from my point of view.

------
peterashford
I mock .NET all the time. I was unaware I needed a framework?

~~~
mfenniak
You don't. It just makes it easier and requires less code.

~~~
insulanian
I think he refers to this meaning of _mocking_ :
[http://www.urbandictionary.com/define.php?term=Mock](http://www.urbandictionary.com/define.php?term=Mock)

------
azurelogic
I'm a big fan of NSubstitute. The syntax makes so much more sense to me than
Moq, and readability matters a lot in unit tests.

~~~
sthomas1618
Agreed. I find NSubstitute incredibly easy to use compared to others.

~~~
kidmenot
Same here. If all projects were like NSubstitute and Dapper I would be much,
much happier.

------
viggity
For anyone that is using Moq, I highly recommend using AutoMoq as well (this
is different from AutoFixture). Everyone knows how frustrating it can be when
you add a dependency to the class under test and all your unit tests fail to
compile. If you use AutoMoq, you just call .Resolve<ClassUnderTest>() and it
will inject a mock for every parameter in the constructor, even if you haven't
explicitly set it up. Dramatically reduces how much "Arrange" code you need to
write.

[https://github.com/darrencauthon/AutoMoq](https://github.com/darrencauthon/AutoMoq)

------
kylemuir
What are peoples thoughts on handrolling mocks\stubs? I tend to do that the
most and would love a compelling reason as to why I should switch my
behaviour.

~~~
smcl
I used to do this before I saw my colleagues tests using Rhino.Mocks. I found
myself willing to write far more/better tests as it got easier to generate
when using the framework than rolling my own.

~~~
kylemuir
I dunno. I've tried mocking frameworks and found that when the interface they
were mocking changed I spent more time trying to fix for the arrange step of
the test than adding tests that added huge value.

Rolling my own might take fractionally more effort to initially set up but the
transparency of what happens and ability to debug through to me is of more
value.

~~~
smcl
Ah so I have luckily not had to experience this as my interfaces have been
relatively stable

------
JackMorgan
The author should add SimpleMock, it's very easy and doesn't clutter the code
with test-only interfaces and DI. You should check out SimpleMock, it's even
easier! [http://deliberate-software.com/simplemock-unit-test-
mocking/](http://deliberate-software.com/simplemock-unit-test-mocking/)

------
solutionyogi
The links in the article are broken because of www prefix.

E.g. NSubsittue is here:
[http://nsubstitute.github.io/](http://nsubstitute.github.io/)

FakeItEasy is here:
[https://fakeiteasy.github.io/](https://fakeiteasy.github.io/)

And even though it's commercial product, one should mention TypeMock.

