The unit test should be doing black box testing on the object under test. - That's something new :) You should not couple tests with implementation, is that what you wanted to say? To test method's contact, not it's implementation.

Quick question... if you're using a mock object framework and you are setting up your expectations in your tests, don't your tests know a lot about the implementation?

This would lead me to think that MVC controllers should be POCOs, infrastructure ignorant.

Can you show a code snippet of what, in your opinion, is a clean controller test?

I'll bite...

"Methods don't have dependencies, and methods aren't dependencies.  Objects are dependencies, and object have dependencies."

If object X has a dependency on object Y, what constitutes this dependency?  Is it not the method calls that object X makes on object Y?  Objects don't have dependencies -- TYPES have dependencies and they're expressed through methods.

"Objects are cohesive and present a contract of behavior so other objects know what behavior they can reliably leverage."

Objects most certainly do NOT present a contract of behavior -- types do.  Moreover, behavior is expressed through methods, not objects.

"Because an object is cohesive, everything necessary to perform all its behavior can be passed into the object's constructor at the beginning of the object's life.  Then, that object can perform all of the operations"

This line of thought seems to make method parameters sort of unnecessary, no?

"In order to test a particular object, I might have to pass some fake objects (stubs, mocks, etc) into the constructor, but the object under test doesn't care as long as the type is satisfied."

Exactly my point -- a contract is expressed through TYPES not objects.

"If I can't test an object by passing in fakes to the constructor (and I can compromise sometimes by using setter injection), then the object is less than cohesive, and I should search the design of the object for an extra concern that is trying to get out.  Once I find the extra concern, I would separate the concern (separation of concerns) into its own object and have than as an explicit dependency by requiring it be passed into the constructor (dependency injection)."

No. You would separate the concern into its own TYPE.  And most likely, you'd express that type's contract through an interface so that you could mock it out for your tests.

"Michael Feathers outlines this extract method and override testing technique in his book..."

Not really sure what any of the above has to do with the extract method and override refactoring?  You were just talking about dependency injection, which is basically a polar opposite of extract and override (with dependency injection, you pass the dependency in, whereas with override and refactor the type itself is responsible for creating an instance of the dependency).

"The unit test should be doing black box testing on the object under test..."

Ditto what Weex said.

Pingback from  Dew Drop - March 12, 2008 | Alvin Ashcraft's Morning Dew

I agree with you in principle and from a testing perspective, but what about a situation like Strategy?  In strategy, I would (usually) invoke the strategy through a method, and typically this is only one method on my object.  I may still inject the strategy interface through the constructor, but it's still a dependency of the method itself as the rest of the object will function correctly without it.  I can test that the strategy is called by using a mock and I probably won't use a mock to test the strategy itself (which I will test separately).  However, I still see this as being a dependency on a method in many cases (although I can think of several exceptions).  Your thoughts?  Also, could methods be dependencies in the case of delegates?  I think that the same argument could be made here.

weex hit it on the head but ...

methods don't have dependencies? functional code I think changes this...

Somebody has already mentioned the Strategy pattern but the first one that came to my mind was specification ...

object.Validate(IEnumerable<Specification<whatever>>)

Pingback from  Reflective Perspective - Chris Alcock  &raquo; The Morning Brew #52

"If a method needs an object in order to function properly, that object should be passed in to a method if it is not  a member of the class."

Now there's a revelation!

"If I can't test an object by passing in fakes to the constructor (and I can compromise sometimes by using setter injection), then the object is less than cohesive"

Not sure I understand this, I think you are saying that a class is not cohesive if all its dependencies are not injected?