This whole thing (that Typemock and other tools like it
leads to poor software design choices) seems to me to be
a really odd position when it comes (as it often does)
from the ALT.NET-leaning people.
One of the premises of ALT.NET (and in fact even the
unofficial 'running with scissors logo' reinforces this)
is that as a dev I am smart enough to make the right
choices for myself and my project even if I am doing so
using tools that offer little or no safety net.
To me, tools like TypeMock and others that support
'potentially' bad ways of working are perfectly fine in
the hands of someone who knows what they are doing --
the idea that tools like TypeMock lead to 'lazy'
developers writing poorly-structured and tightly-coupled
code is just silly if you believe the initial premise:
that TOOLS don't have to lead to good OR bad code but
that its what you do with the tools that makes the
difference.
Personally, as someone who has a significant part of
their professional life spent on janitor duty (cleaning
up the code messes left by other consultants, etc.), I
applaud any move towards more powerful tools that allow
me to work on things in ways I otherwise couldn't.
And that's true of TypeMock Isolator, MOQ, or any other
tools that allow me to introduce workable tests into
systems that otherwise would require blind refactoring
and significant finger-crossing to safely improve the
codebase as I and others work on it.
When I was learning TDD way, Typemock was my first
mocking framework. However, because I was new to TDD I
made a lot of mistakes for which I had to pay later.
Typemock was letting me to mock almost anything and I
was digging deeper and deeper by writing bad tests that
I had to maintain later.
Now; however, I don't mind to switch back to Typemock
because I know what can hurt me (at lest I think I
know).
Power is not bad when you know how to control it. But it
can be dangerous for newbies.
Turn about is fair play :).
I love it.
Roy, manually subclassing to create a test double allows
for exactly the same behaviour.
Moq isn't giving you any power you don't already have in
C#. This technique is pretty common outside of the use
of mocking frameworks (it is even listed in xUnit Test
Patterns.)
Don't think we're comparing apples with apples here :)
Nick
BTW, Roy, Moq allows mocking protected properties and
methods, NOT fields which cannot be mocked just as you
can't override their get/set in your manual C# code.
Maybe that was missleading by my wording ("members"),
but that's what the new feature is for.
We still continue to stay away from voodoo ;)
If Dan had allowed setting expectations on private
members, then I'd be worried. The fact is, protected
means "public to subclasses". Moq now lets you more
easily test those subclass scenarios.
I just used this to assert that a private field was
disposed property. You can't do this using a mock unless
you can access the internal (as the pattern dictates)
virtual Dispose(bool) method.
MoQ FTW.
Personally I think the discussion on TypeMock will
eventually move on.
Currently everyone says IoC and mocking introduce good
design practices, however many then use AMC and (where
possible) automatic dependency hookup because really
they're producing IFooService->FooService style
interfaces.
Truth is good designers produce good designs, where
"good" is totally dependent on the problem/environment
and other factors