ISerializable - Roy Osherove's Blog

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.

You've been kicked (a good thing) - Trackback from DotNetKicks.com

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

Moq never made much sense to me. Daniel's mocking philosophy seemed to not be anywhere near where everyone else was on mocking. So, frankly, this doesn't really shock me and makes even less sense, I guess.

Ayende said that he'd accept a patch for static mocking if someone submitted it to Rhino.Mocks. Like you've said, Roy, there are times where you need it.

Scott Hanselman aptly described TypeMock as a 'crowbar' which is a perfect analogy, I think:

Amazingly useful when its use is appropriate, but rarely is its use appropriate and it can do  some damage if not used at the correct time.

(tech.groups.yahoo.com/.../11195)

My beef with TypeMock is not that it sells crowbars, it's that it sells crowbars as magic tools to solve all problems and that you should continue writing code that only crowbar-like tools can solve. This is harmful to the community, IMHO.

Pingback from  Dew Drop - July 7, 2008 | Alvin Ashcraft's Morning Dew

Funny thing to say Chad, since all of a sudden things that were considered "at the core of mocking" (ayende.com/.../The-RecordReplayVerify-model.aspx) now are being copied from Moq (no explicit record-reply model), or the mixture of stub and mock behaviors in a single object, or the lambda-based syntax, etc. etc.

As Nicholas properly points out, mocking protected members is nothing you can't do with manually created mocks. Moq is there to help you avoid having to create those manual, so it made sense to support something that you can already do (and probably are doing) manually.

How else would you test that your protected members are being called and the base class is behaving as expected in that case with regards to its consumers? It's NOT the same as mocking statics.

I'm surprised that Roy is somehow comparing this to mocking statics "black magic"...

Depending on statics is bad. My guess is Moq will never support it, no matter how many patches I get to support it.

Yes, Moq is an "opinionated" framework at that. We want people to fall in the pit of success, not help them shoot their foot so that they learn how NOT to (precisely what Vadim went through).

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.

My "running with scissors" comment is something I point out in my article on Test Supported Development:

blog.troyd.net/Test+Supported+Development+TSD+Is+NOT+Test+Driven+Development+TDD.aspx

"TypeMock seems to offer a shortcut around these interface extractions, but some TDDers might feel uncomfortable with the power of such a shortcut as it is incongruent with their valuing of TDD's IoC enforcement.

Developers should be free to choose to apply OO design idioms AS THEY SEE FIT. Obviously, good object-oriented design, refactoring, etc. is not exclusively the domain of TDD. Also, I would wager that if developers really wanted an IoC enforcement tool, they would prefer to go searching for (or create) just that [think SRP on a macro level], instead of having it forced upon them as part of a Development Methodology. In fact, a 'Design Principle Enforcement Tool' might not be a bad idea, assuming it does not yet exist."

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