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