Fixes to MockingKernel

[MattHoneycutt]

There are some problems with MockingKernel in the ninject.moq extension as it exists today. I've corrected those, and the resulting container should be a lot more useful as an auto-mocking container. You can see details here: http://trycatchfail.com/blog/post/The-Right-Way-to-Do-Automocking-with-Ninject.aspx.

[WalkerCodeRanger]

This issue needs fixed, but Matt's fix isn't correct. Just because something is self bindable doesn't mean it shouldn't be mocked. We mock lots of classes.

[remogloor]

I discussed this issue with Ian today. I'll integrate this along with a refactoring to use IMissingBindingResolver instead of using obsolete method overrides.

@WalkerCodeRanger. Injection of classes instead of interfaces is generally a bad design. The AutoMocking Kernel should be easy to use to by the majority of projects which will use interfaces for dependencies. The minority of projects which injects classes will have more work but they can still override the default behavior by adding a binding for the calsses they want to be mocked.

[WalkerCodeRanger]

We are following a DDD approach using NHibernate. In that situation it make a lot of sense to mock classes which have all methods virtual so they can be lazy loaded by NHibernate. I don't think that is too uncommon.

If you look at some other auto mocking containers, they handle the situation you discuss by adding a method to create the class under test. Something like Create instead of Get. That makes it easy to use in both the common and "uncommon" case.

[remogloor]

Implemented