
Mocking in .NET - Moving From NMock to Moq - gregbow
http://www.barebonescoder.com/2010/07/mocking-in-net-moving-from-nmock-to-moq/
======
InclinedPlane
It's interesting to me that languages are still a bit primitive in their
seeming indifference to modern software development methodologies.

People often talk about the "next" big languages, and bring up points such as
speed, blending of functional/imperative idioms, cross-platform support, etc.
But though a lot of this is good, important work it's also very much rehashing
old ground. What I think instead we will begin to see within the next decade
or so are languages which take the lessons of modern software development
practices to heart.

For example, consider modular compilers and the ability to perform source
control merges at not just the plain-text line-by-line level but at the parse
tree level.

Or, languages designed with refactoring and IDE auto-completion/intelli-sense
in mind rather than as a bolt-on after-thought.

Or, more to the point, languages which are designed around the ideas of TDD,
BDD, and mocking. To where mocking falls out of the language naturally and
effortlessly, or where TDD is as simple and intuitive as REPL. Instead of as
it is today, where a lot of this work seems like fighting uphill.

~~~
pgbovine
totally agreed; there is an abundance of research in the academic literature
from the past 15 years that still have not been properly commercialized.
technology transfer between academia and industry is often a slow and bumpy
process, but eventually the good ideas will find their way into the
mainstream, i think

(i don't know why you got down-voted for this comment; i just voted you back
up)

~~~
InclinedPlane
Mocking seems to me to be a perfect example. Of how obvious it is that we are
fighting against the flow with so many of our tools and we are merely lacking
the advances in language design which embrace these use cases at their heart.
It seems very similar to the clumsy, piece-meal attempts at procedural
programming through the use of various macros and such-like in the early era
of programming, and later of the attempts at object orientation through
various techniques and conventions. But none of those efforts were able to
fully exploit the potential of procedural programming or object orientation.

You can't just bolt such fundamental shifts in programming idiom and practice
onto existing languages and expect to achieve maximum potency. It often takes
new languages, which have internalized the "paradigm shift", to fully achieve
the potential of transformative development methodologies.

No amount of assembler macros can be as elegant or as effective in
facilitating procedural programming as the C language, for example. Similarly,
you aren't going to create Python within C unless you already have the idea of
Python to work with.

I suspect that these aspects (mocking and unit testing especially) will become
ingrained in future languages to degrees we can hardly imagine. I suspect that
unit testing will be as much a part of many future languages as loops,
assertions, and methods are today, and that running unit tests will be such an
integral part of the build process that it will take explaining to describe
how it's even possible for them to be apart.

Unfortunately, I think too many language designers are too satisfied with the
current state of affairs and don't see the future in these terms.

------
helium
Shameless plug. Moq works beautifully with specr, a BDD framework work I wrote
for .NET 4.0

<http://github.com/michael-erasmus/specr>

------
mullr
I use Moq and enjoy it. I previously used NMock a little bit, and it was a big
pain. The reasons Moq is cool, when compared with other such frameworks,
include:

1) The mock setup routines use a clever and increasingly common hack involving
expression trees (lambdas) to remain strongly typed, which fits nicely with
the rest of the language.

mockObject.SetupGet(ob => ob.prop).Returns(42);

2) You can easily mock out a chain of property accesses with just one call,
rather than having to set up a bunch of intermediate objects.

mockObject.SetupGet(ob => ob.propA.propB.propC).Returns(42);

3) It doesn't matter what order the mocked methods are called in; in many ways
it's more like a dynamic stub generator than a traditional mock object
framework. Some people probably think this is a bad idea; those people can use
another library. I like this mode, I think it makes it a lot easier to start
using. And for testing libraries, that's possibly the most important part.

------
timclark
If you are looking at mocking in .Net, make sure that the framework you select
can easily mock properties and delegates as well as simple method calls. I
don't believe they all do!

~~~
borisk
There are two types of mocking frameworks for .NET. Most, like NMock, Moq,
Rhino Mocks are written in managed code and cannot mock static, sealed or
private methods. On the other hand Typemock Isolator, Telerick JustMock and
Microsoft Moles are using the .NET Profiler API (using that requires some
unmanaged code). The last 3 can even mock stuff from mscorlib, like
DateTime.Now.

