Problem FakeItEasy Ninject WebServer

on a unit test [TestClass] i try to use Ninject and module fakeiteasy but the fakeiteasy dont respect singleton or current object, always create new (different hashcode) on a HttpServer local unit test calling internal with HttpClient, and creating fake object on [TestMethod] things like MustHaveHappend Always fail but another object created and its called.

[TestInitialize]
kernel <-- fakeiteasy  (standarkernel load fakeiteasymodule)
kernel.bind<isomething>.ToMock().InSingletonScope();
config.DependencyResolver = new NinjectResolver(kernel);
HttpServer _server = new HttpServer(config); 
//using Effort too but out of scope here

[TestMethod]
client = new HttpClient(_server);
request = new HttpRequestMessage(); //uri, headers, method, etc
obj = kernel.Get<isomething>();
A.Call.obj ... DoesNothing(); //try with and without
using(response =client.SendAsync(request).Result)
{
   A.Call ... MustHaveHappend  <-- fail
}

if i debug and check HashCode when code execute de Controller on the webapi (project on same solution) [run on the same process, same thread i think (checked on Thread window] and on unittest method check hashcode and they are different objects.

[thomaslevesque]

I can confirm it has nothing to do with FakeItEasy. In fact, it doesn’t even have anything to do with Ninject.MockingKernel: the same behavior can be observed without mocks, like this:

kernel.Bind<ISomething>().To<Something>().InSingletonScope();

Now, I definitely don’t understand either Ninject or ASP.NET MVC, so I’m not sure how good an idea making this change is.

I’m pretty sure it wouldn’t do what @elkami had in mind, at least not on its own.

In ASP.NET (and probably many other backend frameworks), there’s a notion of “request scope”. When a service is registered with request scope, the IoC container will return the same instance during the processing of a given request, but a different one for each request. That’s what the IDependencyResolver.BeginScope method means: begin a request scope in which a fresh instance of each “request-scoped” service will be created.

However, when a service is registered as a singleton, it should always return the same instance for all requests, regardless of scopes.

As far as I can tell, Ninject doesn’t seem to support that. Even without the DependencyResolver infrastructure, just using IKernel.BeginBlock(), Ninject doesn’t reuse instances of singletons but always create a new instance when in a new block. So… Maybe I’m missing something, but Ninject doesn’t seem to properly handle the singleton lifetime, which is the simplest of all. Or, more likely maybe BeginBlock just isn’t supposed to be used that way, and has nothing to do with “scopes” in the ASP.NET sense of the word.

Anyway, there is another package, Ninject.Web.Common, which adds an InRequestScope extension method for when you need a “request scoped” service, and doesn’t seem to rely on BeginBlock. So if you use that, maybe your IDependencyResolver implementation could just return the kernel directly instead of creating a new block, as @blairconrad suggested. See this page for more details.

[blairconrad]

Ah. I made a guess, and it paid off a little. In NinjectResolver, I see

public IDependencyScope BeginScope()
{
    return new NinjectScope(_kernel.BeginBlock());
}

I thought that maybe making the new NinjectScope might interfere, and indeed if you remove the .BeginBlock, your original test passes - the same ISomething is used in the test and by the controller. The test outputs

TestInit 37421455
TestMethod 37421455
Controller Const37421455
Controller Method 37421455

Now, I definitely don’t understand either Ninject or ASP.NET MVC, so I’m not sure how good an idea making this change is. maybe it’s a terrible idea. I don’t know. But so far I don’t see any evidence that FakeItEasy is doing anything wrong.

I think best to follow up at https://github.com/ninject/Ninject.MockingKernel/issues/38, which I’ve just now noticed you created as well. That would’ve been good information to have earlier.