EF Core单元测试首选内存数据库，速度快、隔离性好，通过UseInMemoryDatabase配置独立实例并预置数据；需避免共享DbContext，复杂SQL或依赖真实行为时改用带清理的真实数据库集成测试。
EF Core单元测试的核心思路是：不依赖真实数据库，用轻量、隔离、可重复的方式验证数据访问逻辑是否正确。最常用且推荐的方式是使用 内存数据库（In-Memory Database），它速度快、无外部依赖、天然支持并行测试。
用In-Memory数据库快速搭建测试环境
这是最主流的单元测试方式，适合验证CRUD逻辑、查询条件、关系映射等行为。
- 安装NuGet包：
Microsoft.EntityFrameworkCore.InMemory - 为每个测试创建独立的内存数据库实例，避免数据污染：用
Guid.NewGuid()或测试方法名生成唯一databaseName - 配置上下文选项时调用
.UseInMemoryDatabase("TestDb")，再传入DbContextOptions<TContext>构造上下文 - 测试前可用
AddRange+SaveChanges预置种子数据，无需SQL脚本
测试服务层逻辑（含DbContext依赖）
当业务逻辑封装在Service类中，并通过构造函数注入DbContext时，测试重点是行为而非数据库本身。
dmap-jsapi-skill
下载
DMap GL地图JSAPI（dmapgl）开发指南。用于编写、审查、调试 DMap 地图 API 代码，涵盖地图初始化、覆盖物渲染、图层管理、事件处理、控件交互等任务。当用户提及 dmap、dmapgl、jsapi‑gl 或相关地图开发需求时自动触发。
- 在测试中手动构建
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实例，每个测试应有独立上下文生命周期
基本上就这些。内存数据库够用就别碰真实库；真实库必须测，就做好隔离和清理。不复杂但容易忽略的是数据库名唯一性和种子数据一致性。
