How to overwrite a scoped service with a decorated implementation?
This seems like a limitation of the servicesConfiguration.AddXxx
method which will first remove the type from the IServiceProvider
passed to the lambda.
You can verify this by changing servicesConfiguration.AddScoped<IBarService>(...)
to servicesConfiguration.TryAddScoped<IBarService>(...)
and you'll see that the original BarService.GetValue
is getting called during the test.
Additionally, you can verify this because you can resolve any other service inside the lambda except the one you're about to create/override. This is probably to avoid weird recursive resolve loops which would lead to a stack-overflow.
There's actually a few things here. First, when you register a service with an interface, you can only inject that interface. You are in fact saying: "when you see IBarService
inject an instance of BarService
". The service collection doesn't know anything about BarService
itself, so you cannot inject BarService
directly.
Which leads to the second issue. When you add your new DecoratedBarService
registration, you now have two registered implementations for IBarService
. There's no way for it to know which to actually inject in place of IBarService
, so again: failure. Some DI containers have specialized functionality for this type of scenario, allowing you to specify when to inject which, Microsoft.Extensions.DependencyInjection
does not. If you truly need this functionality, you can use a more advanced DI container instead, but considering this is only for testing, that would like be a mistake.
Third, you have a bit of a circular dependency here, as DecoratedBarService
itself takes a dependency on IBarService
. Again, a more advanced DI container can handle this sort of thing; Microsoft.Extensions.DependencyInjection
cannot.
Your best bet here is to use an inherited TestStartup
class and factor out this dependency registration into a protected virtual method you can override. In your Startup
class:
protected virtual void AddBarService(IServiceCollection services)
{
services.AddScoped<IBarService, BarService>();
}
Then, where you were doing the registration, call this method instead:
AddBarService(services);
Next, in your test project create a TestStartup
and inherit from your SUT project's Startup
. Override this method there:
public class TestStartup : Startup
{
protected override void AddBarService(IServiceCollection services)
{
services.AddScoped(_ => new DecoratedBarService(new BarService()));
}
}
If you need to get dependencies in order to new up any of these classes, then you can use the passed in IServiceProvider
instance:
services.AddScoped(p =>
{
var dep = p.GetRequiredService<Dependency>();
return new DecoratedBarService(new BarService(dep));
}
Finally, tell your WebApplicationFactory
to use this TestStartup
class. This will need to be done via the UseStartup
method of the builder, not the generic type param of WebApplicationFactory
. That generic type param corresponds to the entry point of the application (i.e. your SUT), not which startup class is actually used.
builder.UseStartup<TestStartup>();
All the other answers were very helpful:
- @ChrisPratt clearly explains the underlying problem, and offers a solution where
Startup
makes the service registrationvirtual
and then overrides that in aTestStartup
that is forced upon theIWebHostBuilder
- @huysentruitw answers as well that this is a limitation of the underlying default DI container
- @KirkLarkin offers a pragmatic solution where you register
BarService
itself inStartup
and then use that to overwrite theIBarService
registration completely
And still, I'd like to offer yet another answer.
The other answers helped me find the right terms to Google for. Turns out, there is the "Scrutor" NuGet package which adds the needed decorator support to the default DI container. You can test this solution yourself as it simply requires:
builder.ConfigureTestServices(servicesConfiguration =>
{
// Requires "Scrutor" from NuGet:
servicesConfiguration.Decorate<IBarService, DecoratedBarService>();
});
Mentioned package is open source (MIT), and you can also just adapt only the needed features yourself, thus answering the original question as it stood, without external dependencies or changes to anything except the test project:
public class IntegrationTestsFixture : WebApplicationFactory<Startup>
{
protected override void ConfigureWebHost(IWebHostBuilder builder)
{
base.ConfigureWebHost(builder);
builder.ConfigureTestServices(servicesConfiguration =>
{
// The chosen solution here is adapted from the "Scrutor" NuGet package, which
// is MIT licensed, and can be found at: https://github.com/khellang/Scrutor
// This solution might need further adaptation for things like open generics...
var descriptor = servicesConfiguration.Single(s => s.ServiceType == typeof(IBarService));
servicesConfiguration.AddScoped<IBarService>(di
=> new DecoratedBarService(GetInstance<IBarService>(di, descriptor)));
});
}
// Method loosely based on Scrutor, MIT licensed: https://github.com/khellang/Scrutor/blob/68787e28376c640589100f974a5b759444d955b3/src/Scrutor/ServiceCollectionExtensions.Decoration.cs#L319
private static T GetInstance<T>(IServiceProvider provider, ServiceDescriptor descriptor)
{
if (descriptor.ImplementationInstance != null)
{
return (T)descriptor.ImplementationInstance;
}
if (descriptor.ImplementationType != null)
{
return (T)ActivatorUtilities.CreateInstance(provider, descriptor.ImplementationType);
}
if (descriptor.ImplementationFactory != null)
{
return (T)descriptor.ImplementationFactory(provider);
}
throw new InvalidOperationException($"Could not create instance for {descriptor.ServiceType}");
}
}