使用针对完整 .net 框架的代码，我可以模拟 IDbConnection 和 point it at a mocked DataSet 以测试我的查询是否正确执行。同样，如果我使用的是 EntityFramework 6，我可以有一个 mocked DbSet 返回 IQueryables 并针对它测试我的数据层逻辑。
但是 .net core doesn't support DataSets（尽管这可能会改变 in the future？）。
与此同时，有没有办法创建一个对象集合，dapper 可以使用 IDbConnection 查询以测试查询逻辑？
【问题讨论】：
标签： unit-testing .net-core dapper
不，所有 dapper 都是 IDbConnection 类之上的扩展方法。
没有针对此 (IDbConnection) 的 InMemory 实现（可以理解 SQL 字符串）。
但是，如果您想完全自主地运行它，最好的办法是在每次运行单元测试时启动一个新的 sql 服务器。这可以通过微软为 sqlserver 制作的 docker 镜像轻松完成：https://hub.docker.com/r/microsoft/mssql-server-linux/
或者...
或者迁移到实体框架，它们允许您针对内存中的后备存储进行单元测试。
Dapper 仅包含一些用于生成 SQL 的有用功能。它绝不是从 SQL 中抽象出来的。而 sql 只是 C# 代码的纯文本。它不解析它，也不执行它。因此，如果不使用其背后的数据库，您就无法对您的 sql/dapper 代码进行单元测试。
实体框架的做法不同。它试图将您想要在数据库中执行的所有操作转换为 C# 代码/抽象（例如 IDbCollection）。然后他们制作了 1 个生成 sql 代码的实现和一个使用内存后备存储的实现。这样您就可以对代码进行单元测试。
Microsoft 经常使用Repository Pattern 做广告。这基本上是一个昂贵的词，用于将所有数据库调用/命令抽象为一个单独的类并连接这些类，并在代码中的任何地方使用接口（使用依赖注入）。现在，您可以编写单元测试来测试您对 sql 查询所期望的所有代码，对于这个接口，您可以模拟来测试该方法是否被实际调用。
【讨论】：
另一个测试数据库访问代码（查询等）的选项是使用本地 SQL 数据库实例，但每次您可以在单元测试设置中启动数据库事务时重新创建它，并在拆卸时回滚事务.根据您选择的隔离级别，这还解决了并行执行测试/夹具时的并发问题。
【讨论】：