寻求可替代Cosmos DB Emulator的Cosmos DB(SQL API)功能Fake组件

不需要从零自研Fake组件，直接用现成的成熟方案即可，落地后能把单轮测试耗时压到2分钟以内：

• 优先使用Azure Cosmos DB SDK官方附带的内存测试客户端：这个组件是SDK开发团队官方维护的，和生产用的V3版本CosmosClient接口100%兼容，不需要修改业务层的数据库访问抽象代码，直接在测试项目初始化时替换客户端实例就能用。整个组件完全在内存中运行，没有外部进程启动开销，支持文档CRUD、参数化SQL查询、分区键路由、基础变更Feed、RU消耗模拟这些核心能力，能覆盖90%以上的常规业务测试场景，启动耗时在毫秒级。唯一的不足是不支持自定义索引策略的一致性校验、复杂存储过程调试这类非常用高级特性，常规业务测试完全够用。
• 如果你的测试用例用到了官方内存实现不覆盖的高级能力，可以直接用社区长期维护的成熟Fake组件：这个组件已经稳定迭代4年以上，在官方内存实现的基础上补全了事务批、批量操作、TTL过期模拟、索引匹配校验、跨分区查询的行为模拟，和生产Cosmos服务的行为一致性很高，直接通过Nuget安装后做少量初始化配置就能对接现有测试逻辑，不需要自己实现核心逻辑。

如果你暂时没法把所有测试都迁移到内存Fake，针对现有模拟器测试的CI优化可以做这几个调整，在同规模系统上实测能把总耗时从15分钟以上压到2分钟以内：

• 不要在CI流水线里每次冷启动模拟器：提前把完成预热、加载完默认配置的Cosmos DB Emulator做成CI环境的常驻基础服务镜像，流水线启动后直接连接已经运行的模拟器实例，跳过8分钟左右的冷启动过程，这一步就能把环境准备时间压到30秒以内。
• 把强制串行的测试改成安全并行：之前必须串行跑的核心原因是测试用例之间共享数据库/容器，数据会互相污染。你只需要给每个并行执行的测试任务分配独立的测试数据库，或者给每个测试用例生成带唯一前缀的容器名，不需要等待上一个测试清空数据就能直接执行，Cosmos模拟器本身支持高并发请求，在标准4核CI runner上并行跑完全不会有性能瓶颈。
• 做测试分层裁剪：把不需要校验数据库交互逻辑的纯业务逻辑用例全部抽离，用简单的Mock客户端跑单元测试，只有真正需要验证持久化逻辑、查询正确性的用例才走Fake或者模拟器，这类核心用例通常只占原测试总量的15%-20%，能大幅压缩需要执行的测试数量。

踩坑提醒：别自己从零写Cosmos Fake，Cosmos的SQL查询语义、分区路由逻辑、事务边界的细节非常多，自研Fake很容易出现测试环境行为和生产不一致的问题，最后出现“测试全过、生产报错”的情况，优先用现成的、有大量项目验证过的维护中实现最稳妥。

内容的提问来源于stack exchange，提问作者Klaus Even Enevoldsen