似乎我永远都读过，在测试时，使用模拟数据库对象或存储库。没有理由测试别人的数据库代码，对吧？不需要让您的代码实际上与数据库中的数据混淆，对吧？
最近我看到一些测试建立了一个数据库（可能在内存中）并用测试数据播种它，只是为了运行测试。
一种方法比另一种更好吗？如果带有种子数据的测试值得运行，是否应该为模拟数据库连接而烦恼？如果有，为什么？
【问题讨论】：
标签： database unit-testing testing integration-testing
有很多方法可以测试与数据库交互的代码。
存储库模式是在数据访问代码上创建外观的一种方法。它可以在测试期间轻松存根/模拟存储库。当需要单独测试一段业务逻辑并且虚拟值可以帮助测试代码的不同分支时，这很有用。
假数据库（内存或本地文件）不太常见，因为需要一些“中间件”来知道如何从真实数据库和假数据库中读取数据。在整个事物上拥有一个存储库并模拟存储库通常是有意义的。这种方法在一些已有基础设施的旧系统中更可行。例如，您使用真实数据库，然后出于测试性能原因切换到假数据库。
另一种选择是使用真实的数据库，用虚假数据填充它。这种方法速度较慢，需要编写大量脚本。但是，这种方法作为集成测试的一部分相当普遍。我曾经编写过很多“事务”测试，在这些测试中我使用数据库事务在运行测试后回滚更改。我会编写一个大型测试，在特定表上共同执行我的所有 CRUD 操作。
当您测试将 SQL 结果转换为对象的代码时，最后一种方法很有意义。您的 SQL 可能无效（或者您使用了错误的存储过程名称）。在映射到对象时，也很容易忘记检查空值、执行无效转换等。这段代码应该在某个时候进行测试。 ORM 可以帮助减轻很多此类测试。
这些天我通常很懒惰。我使用存储库。我的大部分数据层代码在执行实际集成测试时都会被触及（使用虚拟数据访问真实数据库），因此我不会费心测试单个数据库调用（不再进行事务测试）。我还使用 ORM 来执行我的大部分 SELECT 语句。我认为很多行业都在朝着这种更懒惰的方式发展。
【讨论】：
你应该同时使用。
业务服务应依赖 DAO，并通过 mock DAO 进行测试。这样可以实现快速、易于实施、易于维护的测试。
DAO 的独特职责是包含数据库访问代码（查询等），并且还应该进行测试。因此，您应该使用带有测试数据的测试数据库，并检查他们的查询是否返回/保存他们支持返回/保存的内容。
我不太喜欢使用内存数据库，这与生产中使用的数据库不同。某些查询、约束等的行为会因数据库而异，您最好确保代码可以在生产数据库上运行，而不是在仅供测试使用的内存数据库中运行。
【讨论】：