Closed fratle closed 12 years ago
A new instance of the kernel should be created for each tests. Furthermore you will want to have Singleton by default otherwise you will not be able to get the mocked objects for setup and verification.
That approach will probably work in most cases, but not when a class is instantiated multiple times (for instance with a ServiceLocator), expecting different instances each time. Also, if class A is dependent on B and C, and B is also dependent on C, we don't necessarily expect both instances of C to be the same.
At least, I think the singleton behaviour should be configurable.
Concerning getting the mocked objects for setup and verification, we do that using reflection and Moq.Get(). To enable per-test bindings, we use a child kernel. This could also be used for setup.
You can always override the default behavior by adding a binding that has a different scope. Defaulting the scope to singleton is correct for the majority of usages. The implementation is done in a way that makes it easy for the majority. The others have to do a bit more.
Probably we can add a configuration for the default scope sometime. But this won't happen soon (unless there is a contribution from the community) as there are much more important things to be done for the project at the moment.
MockingKernel always instantiates its objects as singletons. This breaks testing, because it preserves state between tests. In addition, Ninject will behave differently in tests than in "production".