Why should you care?

ShopNest PlaceOrderHandler must prove FK and unique SKU constraints work — mocks cannot catch migration mistakes.

See it live — copy this example

Paste into a .NET project with EF Core packages, then run with LocalDB/SQL Server (dotnet ef / dotnet run).

public class OrderIntegrationTests : IAsyncLifetime
{
    private ShopNestDbContext _db = null!;

    public async Task InitializeAsync()
    {
        var options = new DbContextOptionsBuilder<ShopNestDbContext>()
            .UseSqlite("DataSource=:memory:")
            .Options;
        _db = new ShopNestDbContext(options);
        await _db.Database.OpenConnectionAsync();
        await _db.Database.EnsureCreatedAsync();
    }

    [Fact]
    public async Task Saves_order_with_items()
    {
        _db.Customers.Add(new Customer { Email = "a@b.com", FullName = "A" });
        await _db.SaveChangesAsync();
        // assert order graph persists
    }

    public async Task DisposeAsync() => await _db.DisposeAsync();
}

What happened?

• SQLite in-memory with open connection persists for test class.
• EnsureCreated builds schema from model.
• Real SaveChanges runs against provider.

Practice next

1. Use WebApplicationFactory for API integration tests with test DB.
2. Reset database per test or use transactions rolled back.
3. Run migrations instead of EnsureCreated for closer production parity.
4. Swap SQLite for Testcontainers SQL Server in CI pipeline.
5. Apply migrations in InitializeAsync instead of EnsureCreated.

Remember

Integration tests hit real EF provider. SQLite or LocalDB common for CI. Validate persistence rules mocks skip.

ShopNest checkout integration

CI runs PlaceOrder integration test against SQLite verifying OrderItems FK after SaveChanges.

Outcome: Broken migration caught before merge to main.