Is Moq too poweful?

Crowdify Blog » Blog Archive » Day 1: Get Moq Working

Crowdify Blog » Blog Archive » Day 1: Get Moq Working — Tue, 02 Dec 2008 05:33:24 GMT

Pingback from Crowdify Blog » Blog Archive » Day 1: Get Moq Working

re: Is Moq too poweful?

Cokin Jack — Sun, 20 Jul 2008 10:44:43 GMT

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

re: Is Moq too poweful?

Troy DeMonbreun — Thu, 10 Jul 2008 22:49:19 GMT

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."

re: Is Moq too poweful?

Will — Wed, 09 Jul 2008 14:36:59 GMT

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.

re: Is Moq too poweful?

Kent Boogaart — Tue, 08 Jul 2008 12:04:19 GMT

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.

re: Is Moq too poweful?

Daniel Cazzulino — Tue, 08 Jul 2008 04:55:43 GMT

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 ;)

re: Is Moq too poweful?

Daniel Cazzulino — Tue, 08 Jul 2008 04:33:29 GMT

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).

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

Dew Drop - July 7, 2008 | Alvin Ashcraft's Morning Dew — Mon, 07 Jul 2008 12:46:29 GMT

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

re: Is Moq too poweful?

Chad Myers — Mon, 07 Jul 2008 00:45:30 GMT

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.

re: Is Moq too poweful?

Nicholas Blumhardt — Sun, 06 Jul 2008 22:22:39 GMT

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