似乎永远我已经读过，在测试时，使用模拟数据库对象或存储库。没理由测试别人的DB代码，对吧？不需要让你的代码实际上弄乱数据库中的数据，对吗？
最近，我看到测试设置了一个数据库（可能是内存中）并用测试数据播种，只是为了运行测试。
一种方法比另一种更好吗？如果使用种子数据进行测试值得运行，那么是否应该使用模拟数据库连接呢？如果是这样，为什么？
答案 0 :(得分：2)
有很多方法可以测试与数据库交互的代码。
存储库模式是一种通过数据访问代码创建外观的方法。它使得在测试期间存根/模拟存储库变得容易。当一块业务逻辑需要隔离测试时，这很有用，虚拟值可以帮助测试代码的不同分支。
虚假数据库（内存或本地文件）不太常见，因为需要一些知道如何从真实数据库和假数据库读取数据的“中间件”。通常在整个事物上有一个存储库并模拟存储库是有意义的。在存在现有基础设施的一些旧系统中，这种方法更为可行。例如，出于测试性能原因，您使用真实数据库然后切换到假数据库。
另一种选择是使用实际数据库，用虚假数据填充它。这种方法较慢，需要编写大量脚本。但是，这种方法作为集成测试的一部分相当普遍。我以前编写了很多“事务”测试，我在运行测试后使用数据库事务来回滚更改。我会写一个大型测试，集中执行我在特定表上的所有CRUD操作。
当您测试将SQL结果转换为对象的代码时，最后一种方法是有意义的。您的SQL可能无效（或使用错误的存储过程名称）。映射到对象时，也很容易忘记检查空值，执行无效转换等。应该在某个时候测试此代码。 ORM可以帮助缓解大量的测试。
这些天我通常很懒。我使用存储库。在执行实际集成测试（使用虚拟数据命中真实数据库）时会触及我的大多数数据层代码，所以我不打扰测试单个数据库调用（不再需要事务测试）。我还使用ORM来完成大部分SELECT语句。我认为很多行业正朝着这种更懒惰的方式发展。
答案 1 :(得分：1)
你应该同时使用它们。
业务服务应该依赖于DAO，并通过模拟DAO进行测试。这样可以实现快速，易于实施，易于维护的测试。
DAO的唯一责任是包含数据库访问代码（查询等），并且还应该进行测试。因此，您应该使用包含测试数据的测试数据库，并检查他们的查询是否返回/保存他们支持返回/保存的内容。
我不是使用内存数据库的忠实粉丝，不同于生产中使用的数据库。某些查询，约束等的行为在数据库与数据库之间会有所不同，您最好确保代码可以在生产数据库上运行，而不是在仅由测试使用的内存数据库中。