search

ninject / Ninject.MockingKernel

Extension for Ninject aiding testability in Moq, NSubstitute, and FakeItEasy
http://ninject.org/
Other
62 stars 25 forks source link

Singleton ScopeCallback breaks testing #8

Closed fratle closed 12 years ago

fratle commented 12 years ago

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

remogloor commented 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.

dabide commented 12 years ago

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.

remogloor commented 12 years ago

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.