在测试数据库调用时，我多次做的就是设置一个数据库，打开一个事务并在最后回滚它。我什至使用了一个内存中的 sqlite 数据库，我在每个测试周围创建和销毁。这有效并且相对较快。
我的问题是：我应该模拟数据库调用，我应该使用上面的技术还是应该同时使用两者 - 一个用于单元测试，一个用于集成测试（至少对我而言，似乎双重工作）。
【问题讨论】：
标签： database unit-testing testing mocking integration-testing
问题在于，如果您使用设置数据库、打开事务和回滚的技术，您的单元测试将依赖于数据库服务、连接、事务、网络等。如果您对此进行模拟，则不会依赖于应用程序中的其他代码片段，并且不会影响您的单元测试结果的外部因素。
单元测试的目标是在不涉及其他应用程序逻辑的情况下测试最小的可测试代码。这在使用您的技术 IMO 时无法实现。
通过抽象数据层使您的代码可测试是一种很好的做法。它将使您的代码更健壮且更易于维护。如果您实现了存储库模式，那么模拟您的数据库调用相当容易。
单元测试和集成测试也满足不同的需求。单元测试是为了证明一段代码在技术上是有效的，并捕捉极端情况。 集成测试根据软件设计验证组件之间的接口。单独的单元测试无法验证一个软件的功能。
HTH
【讨论】：
我要补充到@Stephane 的答案是：这取决于您如何将单元测试融入您自己的个人开发实践中。如果您有端到端集成测试，涉及您创建并根据需要整理的真实数据库 - 前提是您已经涵盖了通过代码的所有不同路径以及用户破解帖子数据可能发生的各种可能性等 - 从测试的角度告诉您系统是否正常工作，这可能是进行测试的主要原因。
我猜想，让您的每个测试都运行在系统的每一层都会使测试驱动开发变得非常困难。需要每一层都到位并工作以使测试通过几乎不包括花费几分钟编写测试、几分钟使其通过并重复。这意味着您的测试不能guide you 就各个组件的行为和交互方式而言；例如，您的测试不会强迫您使事物松散耦合。另外，假设您添加了一个新功能并且在其他地方出现了问题；单独针对组件运行的细粒度测试可以更轻松地跟踪问题所在。
出于这些原因，我认为创建和维护集成和单元测试的“双重工作”是值得的，在后者中模拟或存根您的 DAL。
【讨论】：