Why should you care?

ShopNest handler smoke tests use InMemory for speed when testing non-SQL-specific logic — not for constraint validation.

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).

var options = new DbContextOptionsBuilder<ShopNestDbContext>()
    .UseInMemoryDatabase($"ShopNestTest_{Guid.NewGuid()}")
    .Options;

await using var db = new ShopNestDbContext(options);
db.Products.Add(new Product { Name = "Test", Price = 1, Sku = "T1" });
await db.SaveChangesAsync();

Assert.Equal(1, await db.Products.CountAsync());

What happened?

• Unique database name per test avoids cross-test pollution.
• InMemory accepts SaveChanges without real SQL Server — good for handler wiring tests only.

Practice next

1. Use unique InMemory database name per test class or test.
2. Do not rely on InMemory for FK, unique index, or transaction tests.
3. Prefer SQLite or LocalDB for constraint fidelity.
4. Run same test on InMemory and SQLite — compare failure differences on FK test.
5. Seed InMemory with HasData equivalent manual Add in test setup.

Remember

InMemory is fast isolated fake DB. Behavior differs from SQL Server. Use for simple CRUD handler smoke tests.

ShopNest handler smoke

MediatR handler tests use InMemory to verify handler calls SaveChanges once.

Outcome: Fast feedback; SQL fidelity tests run separately in integration job.