EF Core单元测试的核心思路是：不依赖真实数据库，用轻量、隔离、可重复的方式验证数据访问逻辑是否正确。最常用且推荐的方式是使用 内存数据库（In-Memory Database），它速度快、无外部依赖、天然支持并行测试。
用In-Memory数据库快速搭建测试环境
这是最主流的单元测试方式，适合验证CRUD逻辑、查询条件、关系映射等行为。
安装NuGet包：Microsoft.EntityFrameworkCore.InMemory为每个测试创建独立的内存数据库实例，避免数据污染：用
Guid.NewGuid()或测试方法名生成唯一
databaseName配置上下文选项时调用
.UseInMemoryDatabase("TestDb")，再传入DbContextOptions<tcontext></tcontext>构造上下文 测试前可用
AddRange+
SaveChanges预置种子数据，无需SQL脚本
测试服务层逻辑（含DbContext依赖）
当业务逻辑封装在Service类中，并通过构造函数注入
DbContext时，测试重点是行为而非数据库本身。 在测试中手动构建
DbContextOptions，传给Service构造函数，或通过DI容器注册内存上下文 验证方法返回结果是否符合预期，比如
GetTopBooksByPublisher("xxx")是否真返回10条且Publisher匹配
不必Mock DbContext——它本身不是接口，但In-Memory提供程序已足够模拟行为
若需验证“是否执行了某次SaveChanges”，可检查context.ChangeTracker.HasChanges()或断言实体状态
需要连接真实数据库的场景怎么测
某些逻辑绕不开SQL Server、Cosmos DB等真实行为（如复杂索引、存储过程、事务隔离级别、JSON列处理），这时要走集成测试路线。
用临时数据库名（如"Test_" + Guid.NewGuid()）确保每次测试干净起步 调用
EnsureDeletedAsync()+
EnsureCreatedAsync()重置结构和数据 连接字符串建议从配置读取，测试项目中单独配
appsettings.Test.json慎用事务回滚替代清理——In-Memory不支持，SQL Server上也需注意异步/跨上下文问题
辅助技巧提升测试质量
让测试更清晰、易调试、少陷阱。
开启EF日志：在OnConfiguring里加
optionsBuilder.LogTo(Console.WriteLine, LogLevel.Information)，查看实际生成的SQL 对复杂查询，用
query.ToQueryString()直接拿到SQL字符串做断言（EF Core 5+） 种子数据多时，用JSON文件存放，测试中反序列化后批量插入，便于维护和复用 避免在多个
[Test]方法间共享同一个DbContext实例，每个测试应有独立上下文生命周期
基本上就这些。内存数据库够用就别碰真实库；真实库必须测，就做好隔离和清理。不复杂但容易忽略的是数据库名唯一性和种子数据一致性。
