Comments on: Ninject.RhinoMocks: Auto Mocking Container For .NET 3.5 and Compact Framework 3.5

By: Justice~!

Justice~! — Sat, 22 May 2010 16:10:42 +0000

@Derick, I don’t know man – the pain of that had been pretty minimal for me! But then again once you get into larger domain spaces it might be more difficult to keep track, so I can see the other side too.

By: derick.bailey

derick.bailey — Sat, 22 May 2010 01:16:04 +0000

@Louis – yeah, that’s the “big problem” that people complain about when they say auto mocking containers are bad. honestly, that’s a pretty weak excuse for not teaching developers how to spot too many dependencies as a part of bad design. trust your team. if they get it wrong, teach them right. :)

@Justice – that would only distribute the problem. rather than having my mocks setup in the area that they are used, i’d have to register them in a completely different class. worse, i wouldn’t know whether or not they were registered already, so i’d have to constantly check to see if they are when i am setting up a class to be tested.

By: Justice~!

Justice~! — Fri, 21 May 2010 22:24:53 +0000

I’m a bit surprised you didn’t just use a different Ninject module for testing that used rhinomocks to return a mocked dependency; would seem to be the easiest way?

By: Louis Salin

Louis Salin — Fri, 21 May 2010 22:04:02 +0000

I’ve heard (or read…) that automocking is equivalent to taking weight loss pills while still eating cheesburgers for breakfast. Okay, I just made that up!

My point is, and I’m in no way in a position to opine on the matter, that the pain of mocking might be due to design issues. Hiding the pain with a tool won’t make the cause go away.

So maybe in this case it’s a very benign use of an automocker, but as the code base grows, the automocker will hide pain points that would otherwise become immediately obvious, no?