Java TDD场景下DAO无返回值方法测试：假实现vs内存数据库选型

背景 #

我基于Java 17、Dropwizard和JUnit 5开发项目，正在践行TDD并优化单元测试。应用通过DAO接口与数据库交互，目前在探索这类交互的最佳测试方案，尤其针对插入数据这类无返回值的方法。

我考虑了两种方案：

• 假实现（Fake Implementations）：创建DAO接口的内存假实现，模拟数据库操作
• 内存数据库（In-Memory Databases）：用H2等内存数据库，在受控环境执行真实数据库操作

我知道假实现无需真实数据库连接，速度快、简洁，适合单元测试；内存数据库提供更真实的环境，适合验证SQL查询和事务行为的集成测试。

问题 #

1. 在TDD场景下，兼顾测试速度与真实性，针对无返回值的DAO方法应选用哪种方案？
2. 是否存在特定场景或项目阶段，其中一种方案明显更具优势？

我希望构建可靠、可维护且符合TDD最佳实践的测试策略，求分享见解、经验与建议。

解答 #

1. TDD场景下的折中方案：分层测试，两者结合 #

TDD的核心是快速反馈+验证逻辑正确性，完全依赖某一种方案都有短板，建议分层测试，两者搭配使用：

• 单元测试用Fake实现：针对DAO接口的调用方（比如Service层），用Fake DAO快速验证业务逻辑是否正确触发了DAO的操作（比如调用了insert方法）。对于无返回值的方法，可以在Fake里维护一个内存状态（比如一个List），测试时插入后直接检查这个List是否新增了对应数据，既快又能验证交互逻辑。
• 集成测试用内存数据库：单独针对DAO层的实现类，用H2执行真实的SQL插入，验证SQL语法、约束（比如主键唯一、非空字段）、事务行为是否符合预期。这部分测试不用跑太频繁，但能覆盖Fake模拟不到的真实数据库行为。

针对无返回值的方法，单元测试阶段用Fake能快速完成TDD的"红-绿-重构"循环，而集成测试用内存数据库补全真实场景的验证，兼顾了速度和真实性。

2. 特定场景/阶段的方案选择 #

优先选Fake实现的场景：

• 项目初期（TDD快速迭代阶段）：此时DAO的SQL逻辑还不稳定，业务逻辑是迭代核心。用Fake可以快速搭建测试脚手架，不用花时间配置数据库、初始化schema，专注于业务逻辑的验证。
• 测试业务逻辑而非DAO实现：当你要测试Service层是否正确调用了DAO的插入方法，而不是验证SQL本身时，Fake足够用。比如测试"用户注册时是否调用了insertUser"，Fake的内存状态检查比数据库查询更高效。
• 需要快速执行的测试套件：比如CI流水线里的快速验证阶段，Fake测试跑起来毫秒级，能快速反馈代码是否破坏了核心逻辑。

优先选内存数据库的场景：

• DAO层逻辑复杂时：比如插入操作涉及多表关联、事务回滚、触发器、复杂SQL（比如批量插入、带条件的插入），Fake很难模拟这些真实数据库行为，必须用内存数据库验证SQL的正确性。
• 需要验证数据库约束时：比如插入重复主键、缺少非空字段时，数据库会抛出异常，Fake如果没特意实现这些约束，就测不出来。内存数据库能真实复现这些场景。
• 项目后期（稳定阶段）：此时业务逻辑趋于稳定，需要确保DAO的实现和生产环境的数据库行为一致，内存数据库的测试能降低线上SQL问题的风险。

额外建议 #

• Fake实现要保持简洁：只实现测试需要的逻辑，不要过度模拟数据库的所有特性，否则会变成另一个"内存数据库"，增加维护成本。比如针对插入方法，只需要记录插入的数据即可，不用实现查询、删除的复杂逻辑。
• 内存数据库测试要隔离：每个测试用例执行前清空表或者重建schema，避免测试数据污染。Dropwizard本身有测试扩展可以帮你管理H2的生命周期，结合JUnit 5的@BeforeEach或者@TestInstance来做初始化。
• 不要用Fake替代所有DAO测试：即使是无返回值的方法，也需要少量集成测试来验证SQL的正确性，避免出现"Fake里逻辑正确，但真实SQL写错了"的情况。

内容的提问来源于stack exchange，提问作者Kamil Gajdzinski