Not Able to UseInMemoryDatabase with WebApplicationFactory

[OdeToCode]

This is related, I think, to the confusion expressed in dotnet/efcore#17224. No matter what I try, I cannot get an InMemoryDatabase into the service collection for an ASP.NET Core app. This was a scenario that was working by following the docs, but isn't working since I moved to 3.0.

Steps to reproduce

I'm using the code from this directory in my repository: https://github.com/OdeToCode/explore-aspnetcore/tree/master/All/test/TestTheTest

You should be able to download the folder and dotnet build / dotnet test the solution.

The idea is to run integration tests against an ASP.NET Core application by swapping out a DbContext configured to use SQL Server with a DbContext configured for in-memory. The web app configures services like so:

public void ConfigureServices(IServiceCollection services)
{
    services.AddDbContext<SomeDbContext>(options =>
    {
        options.UseSqlServer("fail");
    });
}

The tests use a custom WebApplicationFactory in an attempt to override the DbContext options.

public class CustomWebFactory : WebApplicationFactory<Startup>
{
    protected override IHostBuilder CreateHostBuilder()
    {
        return Host.CreateDefaultBuilder()
                   .ConfigureWebHostDefaults(c =>
                   {
                       c.UseStartup<Startup>();
                   });
    }

    protected override void ConfigureWebHost(IWebHostBuilder builder)
    {
        builder.ConfigureServices(services =>
        {
            services.AddDbContext<SomeDbContext>(options =>
            {
                options.UseInMemoryDatabase("DB");
            });
        });
    }
}

The test in the project uses a simple piece of middleware to look at the configured provider for the DbContext at runtime.

public async Task Invoke(HttpContext ctx, SomeDbContext db)
{
    if (ctx.Request.Path.StartsWithSegments("/db"))
    {
        await ctx.Response.WriteAsync(db.Database.ProviderName);
    }
    else
    {
        await next(ctx);
    }
}

I am able to override and change other services in the WebApplicationFactory, except for the DbContext options. The only technique that seems to work is to remove the call to options.UseSqlServer in the web app - then the factory override does take hold. From what I can tell, execution never reaches the options builder of the test factory, so no combination of service caching and UseInternalProvider work.

Further technical details

EF Core version: 3.0.0
Database provider: Microsoft.EntityFrameworkCore.SqlServer and InMemory
Target framework: .NET Core 3.0
Operating system: Win10-x64
IDE: VS2019

[OdeToCode]

Wondering if the behavior I see is because DbContextOptions, once set in the service provider, are not overwritten.

serviceCollection.TryAdd(new ServiceDescriptor(typeof(DbContextOptions<TContextImplementation>), (IServiceProvider p) => DbContextOptionsFactory<TContextImplementation>(p, optionsAction), optionsLifetime));

[OdeToCode]

I think my problem is that once the DbContextOptions are set in the app, the test cannot change the options. The options are placed into the service collection using TryAdd, which won't overwrite. This behavior changed in the move to 3.0, no?

[OdeToCode]

I can get the test fixtures to use the in-memory database by making sure I overwrite DbContextOptions in the WebApplicationFactory. In other words, instead of:

services.AddDbContext<SomeDbContext>(options =>
{
    options.UseInMemoryDatabase("DB");
});

I'm using:

ReplaceCoreServices<SomeDbContext>(services, (p, o) =>
{
    o.UseInMemoryDatabase("DB");
}, ServiceLifetime.Scoped);

Where ReplaceCoreServices looks like:

private static void ReplaceCoreServices<TContextImplementation>(IServiceCollection serviceCollection, 
                                        Action<IServiceProvider, DbContextOptionsBuilder> optionsAction, 
                                        ServiceLifetime optionsLifetime) where TContextImplementation : DbContext
{
    serviceCollection.Add(new ServiceDescriptor(typeof(DbContextOptions<TContextImplementation>), 
                          (IServiceProvider p) => DbContextOptionsFactory<TContextImplementation>(p, optionsAction), optionsLifetime));
    serviceCollection.Add(new ServiceDescriptor(typeof(DbContextOptions), 
                          (IServiceProvider p) => p.GetRequiredService<DbContextOptions<TContextImplementation>>(), optionsLifetime));
}

private static DbContextOptions<TContext> DbContextOptionsFactory<TContext>(IServiceProvider applicationServiceProvider, 
                                           Action<IServiceProvider, DbContextOptionsBuilder> optionsAction) where TContext : DbContext
{
    DbContextOptionsBuilder<TContext> dbContextOptionsBuilder = new DbContextOptionsBuilder<TContext>(
        new DbContextOptions<TContext>(new Dictionary<Type, IDbContextOptionsExtension>()));
    dbContextOptionsBuilder.UseApplicationServiceProvider(applicationServiceProvider);
    optionsAction?.Invoke(applicationServiceProvider, dbContextOptionsBuilder);
    return dbContextOptionsBuilder.Options;
}

[joakimriedel]

@OdeToCode looks like you've already found a successful workaround, but wanted to add in that I had the same issue migrating to 3.0. Ended up setting Test environment in WebApplicationFactory and having two configuration paths, ConfigureServices and ConfigureTestServices (by convention), where the latter shares the same code except using InMemory.

[OdeToCode]

@jcemoller Yes, I like that approach better. My factory now looks like the following. Setting the environment allows for the different Configure methods to execute.

public class MyWebFactory : WebApplicationFactory<Startup>
{
    protected override IHostBuilder CreateHostBuilder()
    {
        return base.CreateHostBuilder()
                   .UseEnvironment("IntegrationTests");
    }
    // ...

[ajcvickers]

@OdeToCode @jcemoller After investigating this I don't believe that the change in behavior is coming from EF Core. I downgraded EF Core to 2.2.6 in the test project and observed the same behavior. Further investigation leads me to believe that the two calls to AddDbContext are now being called in a different order.

I'm going to move this to the AspNet repo for further investigation.

[javiercn]

@OdeToCode Thanks for contacting us.

This is a result of the move to generic web host, where the order of the ConfigureServices callbacks is different. We have a docs issue tracking the documentation update here.

I believe your solution is identical to the one I provided here

I'm going to go ahead and close this issue, as it's not really a WAF issue but an issue with the docs.

I'll see if I can get this doc prioritized given the number of people that are running into this.

[JayConnerGhost]

I have ended up doing the following in the Startup.cs file and setting the enviroment in the WebApplicationFactory to IntegrationTests. I hate this i feel like im polluting production code with test code...

public void ConfigureServices(IServiceCollection services)
        {
            //HACK 
            IServiceProvider serviceProvider = services.BuildServiceProvider();
            var env = serviceProvider.GetService<IHostingEnvironment>();
            //logic in here to configure correct DB 
            if (env.IsEnvironment("IntegrationTests"))
            {
                services.AddEntityFrameworkInMemoryDatabase();
                
                services.AddDbContext<ApplicationDbContext>(options =>
                {
                    options.UseInMemoryDatabase("InMemoryDbForTesting");
                });
            }
            else
            {
                services.AddDbContext<ApplicationDbContext>
                    (options => options.UseSqlServer(Configuration.GetConnectionString("CrystalProcessDatabase")));

            }

            services.AddControllers();
        }