Why does my app migrate fine but my tests say the model has pending changes?

The EF Core model depends on options resolved from dependency injection, not only on your DbContext code. If the tests build DbContextOptions without the same services, for example Identity's SchemaVersion, they build a different model than the app and it no longer matches the migration snapshot.

How do I suppress PendingModelChangesWarning in EF Core?

Call ConfigureWarnings on the options builder and ignore RelationalEventId.PendingModelChangesWarning. Do this only when you know why the model differs from the snapshot. If the message is simply true, add a new migration instead.

What does Identity's Stores.SchemaVersion change?

It selects the shape of the ASP.NET Core Identity tables in the EF Core model. Version 3, used by ClinicLive on .NET 10, adds the tables and columns for passkey support. Because it changes the model, every place that builds the context, including test fixtures, must set the same value.

EF Core: 'The model for context has pending changes' in tests while the app migrates fine

The model for context 'ApplicationDbContext' has pending changes. Add a new migration before updating the database. — EF Core built a model that does not match your last migration's snapshot, and since EF Core 9 Migrate() treats that as an error rather than a warning.

Usually the message is right and you forgot a migration. The confusing case is when the app migrates the same database happily and only your tests hit it. Then the model itself differs between the two, because the model is not just your DbContext: options from dependency injection shape it too. ClinicLive sets Identity's Stores.SchemaVersion in Program.cs, which changes the Identity tables; the test fixture built its options without it. Give the tests the same IdentityOptions through UseApplicationServiceProvider and the models agree again.

The error

From the first run of the test suite (abridged — the log kept the sentence, not the stack):

System.InvalidOperationException: The model for context 'ApplicationDbContext' has pending
changes. Add a new migration before updating the database.
  (followed by the usual hint about suppressing RelationalEventId.PendingModelChangesWarning
   through ConfigureWarnings)

Why it happens

Before applying migrations, EF Core compares the model it just built with the model snapshot stored alongside your migrations. Any difference raises PendingModelChangesWarning, which is configured to throw by default. The check is honest: if the two differ, running the migrations would leave the database out of step with the code.

IdentityDbContext.OnModelCreating reads IdentityOptions from the application's service provider, and Stores.SchemaVersion decides which Identity tables and columns exist — version 3 adds the passkey support that arrived in .NET 10. The app configures that in AddIdentityCore, so its model matches the snapshot. The test fixture created DbContextOptions by hand with no service provider, Identity fell back to its default schema version, and the test-built model was a different model.

The fix

// tests/ClinicLive.Tests/PostgresFixture.cs
// The app sets Identity's store schema version through DI (Program.cs), and
// that setting shapes the MODEL. Without it, the test-built model wouldn't
// match the migration snapshot and EF refuses to migrate ("pending changes").
var identityServices = new ServiceCollection()
    .Configure<IdentityOptions>(o => o.Stores.SchemaVersion = IdentitySchemaVersions.Version3)
    .BuildServiceProvider();

var options = new DbContextOptionsBuilder<ApplicationDbContext>()
    .UseNpgsql(ConnectionString)
    .UseSnakeCaseNamingConvention()
    .UseApplicationServiceProvider(identityServices)
    .Options;

Two alternatives, each for a different situation. If the message is simply true, add the migration. If you have a deliberate reason for a model that differs from the snapshot, suppress the check knowingly: .ConfigureWarnings(w => w.Ignore(RelationalEventId.PendingModelChangesWarning)). Do not reach for that one to make a test pass.

Where it bit us

Season one, Part 9 (tag part-09 in the repo), the first run of the xUnit suite against a real PostgreSQL in Testcontainers. The app had migrated that same image minutes earlier, which is what made the message confusing, and the diagnosis was a genuinely good AI conversation. The lesson the part kept: the model lives in DI. Anything that configures your context at startup — naming conventions, Identity options, value converters registered as services — has to reach the tests too, or the tests are testing a different schema.

Frequently asked

Why does my app migrate fine but my tests say the model has pending changes?: The EF Core model depends on options resolved from dependency injection, not only on your DbContext code. If the tests build DbContextOptions without the same services, for example Identity's SchemaVersion, they build a different model than the app and it no longer matches the migration snapshot.
How do I suppress PendingModelChangesWarning in EF Core?: Call ConfigureWarnings on the options builder and ignore RelationalEventId.PendingModelChangesWarning. Do this only when you know why the model differs from the snapshot. If the message is simply true, add a new migration instead.
What does Identity's Stores.SchemaVersion change?: It selects the shape of the ASP.NET Core Identity tables in the EF Core model. Version 3, used by ClinicLive on .NET 10, adds the tables and columns for passkey support. Because it changes the model, every place that builds the context, including test fixtures, must set the same value.

More decoded errors in the Fixes category; the test suite this came from starts at From Prompt to Production, Part 1.