在 Java 中测试 DAO 方法：假实现与内存数据库

Question

我目前正在使用 Java 17、Dropwizard 和 JUnit 5 开发一个 Java 项目，我专注于改进我的单元测试并采用测试驱动开发 (TDD) 实践。我的应用程序通过 DAO 接口与数据库交互，我正在探索测试这些交互的最佳方法，特别是对于执行向数据库插入数据等操作但不返回值的方法。

考虑到这些方法的性质，我正在考虑两种主要的测试方法：

1. 使用假实现：创建 DAO 接口的假实现来模拟内存中的数据库操作
2. 使用内存数据库：利用H2等内存数据库在受控环境中执行真正的数据库操作。

我知道假实现通过避免设置真实数据库连接的开销来提供速度和简单性，使它们成为单元测试的理想选择。另一方面，内存数据库提供了更真实的测试环境，这似乎有利于集成测试，以确保我的 SQL 查询和事务按预期运行。

我的问题：

1. 在 TDD 的背景下，考虑测试中速度和真实性之间的平衡，对于不返回值的测试方法，您会推荐哪种方法？
2. 是否存在特定场景或项目阶段，其中一种方法明显优于另一种方法？

我的目标是制定一种测试策略，不仅确保可靠性和可维护性，而且符合 TDD 的最佳实践。如果您能分享任何见解、经验或建议，我们将不胜感激。

谢谢！

Answer 1

两者都做。应用测试金字塔中的经验教训。大多数测试应该运行得很快，当完全在内存中运行时通常效果最好。另一方面，可能会出现此类测试无法排除的实现错误或错误，因此请使用较小的集成测试集来增强单元测试。

我通常建议集成测试使用也将在生产中使用的数据库技术。因此，除非您还计划在生产中使用内存数据库，否则不要使用内存数据库进行集成测试。如果您在生产中使用 Oracle，请针对 Oracle 运行集成测试等。

大多数数据库技术使您能够完全自动化数据库的创建、配置和拆卸，因此请确保将数据库自动化作为标准“四阶段测试模式”的一部分。换句话说，不要针对共享的“测试数据库”运行集成测试，而是确保每个集成测试针对仅用于此目的的隔离数据库运行。我通常在测试的“设置”阶段创建数据库，并在测试的“拆卸”阶段再次删除它。

xUnit Test Patterns

有很多有用的信息，以及许多与单元测试相关的其他内容。