我正在尝试增加整体集成测试执行时间，我目前正在评估各种内存数据库解决方案。这个想法是让DAO在测试期间遇到内存数据库而不是命中真正的数据库。这是一个使用Hibernate进行持久化的Java应用程序。
我很想看到您使用其中一种产品H2，Derby，HSQLDB，Oracle Berkeley DB的经验。
我的一些顾虑是：内存数据库是否能够执行存储过程，自定义本机sql？您是否可以有选择地选择哪个服务应该在真实数据库中与内存数据库相比？
总的来说，由于这种方法涉及数据库引导（预加载/预创建所有带数据的表），我现在在想是否只是简单地模拟DAO层而不是担心所有的mem DB中可能带来的未知问题...
感谢。
答案 0 :(得分：5)
我的建议是测试一切，包括你提到的DAO层。但看看你是否可以分片测试。服务，DAO，UI。
对于服务层测试，模拟DAO。这样，服务层测试与DAO是否正常工作无关。如果服务层测试使用DAO并使用真实数据库，那么我认为它不是真正的单元测试而是集成测试。虽然它们也很有价值，但如果它们失败了，它就不会像单元测试一样找出问题。
对于我们的DAO层测试，我们将DbUnit与 HSQLDB 一起使用。 （如果你使用Spring / Hibernate / DbUnit将它们组合在一起，使用Unitils是有帮助的。）我们的DAO测试执行得很好而且很快（当你有500多个测试时这很重要）。内存db模式是从我们的模式创建脚本构建的，所以我们也在测试它们的副作用。我们将一些已知数据从一些平面文件加载/刷新到内存数据库中。 （与我们使用DEV数据库时相比，某些数据会被删除然后破坏测试）。 此解决方案对我们很有用，我会向任何人推荐。
但请注意，我们无法以这种方式测试使用存储过程的DAO（但我们只有一个）。我对提到使用不同数据库“糟糕”的海报有点不同意 - 只要注意这些差异并了解这样做的含义。
你没有提到你是否正在使用Hibernate - 这是一个重要的因素，因为它抽象我们远离修改任何可能特定于Oracle或SQLServer或HSQLDB的SQL，这是另一张海报提到的。
答案 1 :(得分：1)
模拟DAO层。
除非您只是使用普通的sql，否则数据库之间的细微实现差异和不同的功能集将限制您可以执行的操作（存储过程，视图等），并且在某种程度上也会使测试无效。
我个人的嘲弄框架是Mockito。但是有很多工作要做，并且嘲笑DAO是标准做法，所以你会找到很多文档。
答案 2 :(得分：1)
为单元测试和生产提供不同的数据库是个坏主意。
BTW，在真实数据库中测试应该很快，可能你在测试中做错了。答案 3 :(得分：1)
我刚刚在mem db中遇到了Oracle Times Ten。 http://www.oracle.com/technology/products/timesten/index.html
这似乎可能是最无痛的解决方案。由于不需要额外的模拟/配置。您仍然可以使所有集成测试完好无损地访问数据库，但现在数据传输速度更快。你们觉得怎么样？