我使用第一种方法(针对测试数据库运行代码)。我看到您用这种方法提出的唯一实质性问题是模式不同步的可能性，我通过在数据库中保留一个版本号并通过一个脚本对每个版本增量应用更改来处理这个问题。

我还首先对测试环境进行了所有更改(包括对数据库模式的更改)，因此结果正好相反:在所有测试通过之后，将模式更新应用到生产主机。我还在我的开发系统上保留了一对单独的测试数据库和应用程序数据库，这样我就可以在接触真正的生产系统之前验证数据库升级是否正常工作。

我一直在问这个问题，但我认为没有解决这个问题的灵丹妙药。

我目前所做的是模拟DAO对象，并在内存中保持一个良好的对象集合的表示，这些对象表示可能存在于数据库中的有趣的数据情况。

The main problem I see with that approach is that you're covering only the code that interacts with your DAO layer, but never testing the DAO itself, and in my experience I see that a lot of errors happen on that layer as well. I also keep a few unit tests that run against the database (for the sake of using TDD or quick testing locally), but those tests are never run on my continuous integration server, since we don't keep a database for that purpose and I think tests that run on CI server should be self-contained.

我发现另一种方法非常有趣，但并不总是值得的，因为它有点耗时，那就是在只在单元测试中运行的嵌入式数据库上创建用于生产的相同模式。

尽管毫无疑问，这种方法提高了您的覆盖率，但也有一些缺点，因为您必须尽可能接近ANSI SQL，以使其与当前的DBMS和嵌入式替代品一起工作。

无论您认为哪个项目与您的代码更相关，都有一些项目可以使它更简单，比如DbUnit。

我使用第一种方法(针对测试数据库运行代码)。我看到您用这种方法提出的唯一实质性问题是模式不同步的可能性，我通过在数据库中保留一个版本号并通过一个脚本对每个版本增量应用更改来处理这个问题。

我还首先对测试环境进行了所有更改(包括对数据库模式的更改)，因此结果正好相反:在所有测试通过之后，将模式更新应用到生产主机。我还在我的开发系统上保留了一对单独的测试数据库和应用程序数据库，这样我就可以在接触真正的生产系统之前验证数据库升级是否正常工作。

对于基于JDBC的项目(直接或间接地，例如JPA, EJB，…)，您不能模拟整个数据库(在这种情况下，在真正的RDBMS上使用测试数据库会更好)，但只能在JDBC级别模拟。

这样做的好处是抽象，因为JDBC数据(结果集、更新计数、警告……)无论在后端是什么:您的prod db、测试db，还是为每个测试用例提供的一些模型数据，都是相同的。

通过为每种情况模拟JDBC连接，不需要管理测试db(清理，一次只进行一个测试，重新加载fixture，等等)。每个模拟连接都是隔离的，不需要清理。每个测试用例中只提供了模拟JDBC交换所需的最低限度的fixture，这有助于避免管理整个测试数据库的复杂性。

Acolyte是我的框架，它包括用于这种模型的JDBC驱动程序和实用程序:http://acolyte.eu.org。

出于以下原因，我总是对内存中的DB (HSQLDB或Derby)运行测试:

它使您考虑在测试DB中保留哪些数据以及为什么要保留这些数据。仅仅将您的生产DB拖到测试系统中就意味着“我不知道我在做什么，也不知道为什么，如果有什么东西坏了，那肯定不是我!!”；） 它确保可以在新的地方轻松地重新创建数据库(例如，当我们需要从生产中复制一个错误时)。 它极大地提高了DDL文件的质量。

一旦测试开始，内存中的DB就会加载新的数据，在大多数测试之后，我调用ROLLBACK以保持它的稳定。始终保持测试DB中的数据稳定!如果数据一直在变化，就不能进行测试。

数据从SQL、模板DB或转储/备份加载。我更喜欢转储文件，如果它们是可读的格式，因为我可以把它们放在VCS中。如果这不起作用，我就使用CSV文件或XML。如果我必须加载大量的数据……我不喜欢。你永远不需要加载大量的数据:)单元测试不需要。性能测试是另一个问题，适用的规则不同。

即使有允许您以某种方式模拟数据库的工具(例如jOOQ的MockConnection，可以在这个回答中看到-免责声明，我为jOOQ的供应商工作)，我也建议不要用复杂的查询模拟大型数据库。

即使您只是想对ORM进行集成测试，也要注意ORM会向数据库发出一系列非常复杂的查询，这些查询可能在

语法 复杂性 订单(!)

模拟所有这些以产生合理的虚拟数据是相当困难的，除非您实际上在模拟中构建了一个小数据库，它解释传输的SQL语句。话虽如此，请使用一个知名的集成测试数据库，您可以很容易地使用知名数据重置该数据库，并针对该数据库运行集成测试。