简单可靠的内存数据库，用于快速 Java 集成测试并支持 JPA
如果我使用内存数据库而不是 PostgreSQL，我的集成测试会运行得更快。我使用 JPA (Hibernate)，并且需要一个内存数据库，该数据库可以轻松切换到使用 JPA、易于设置且可靠。它需要相当广泛地支持 JPA 和 Hibernate（或者反之亦然），因为我不想采用我的数据访问代码进行测试。
考虑到上述要求，哪个数据库是最佳选择？
My integration tests would run much faster if I used in-memory-database instead of PostgreSQL. I use JPA (Hibernate) and I need an in-memory-database that would be easy to switch to using JPA, easy to setup, and reliable. It needs to support JPA and Hibernate (or vice verse if you will) rather extensively since I have no desire to adopt my data access code for tests.
What database is the best choice given requirements above?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
对于集成测试，我现在使用我更喜欢的H2（来自HSQLDB的原作者）通过 HSQLDB。它更快（我希望我的测试尽可能快），它有一些不错的功能，例如 兼容性 模式，开发团队反应非常灵敏（而 HSQLDB 仍处于休眠状态）多年来直到最近）。
For integration testing, I now use H2 (from the original author of HSQLDB) that I prefer over HSQLDB. It is faster (and I want my tests to be as fast as possible), it has some nice features like the compatibility mode, the dev team is very responsive (while HSQLDB remained dormant for years until very recently).
我一直在使用 HSQLDB 内存 用于在 Java 中集成测试 JPA/Hibernate 持久性。启动很快，不需要任何特殊设置。
到目前为止，我在 Hibernate 中使用 HSQLDB 遇到的唯一问题是批处理大小需要设置为 0，但这可能与旧版本有关。我会进行挖掘，看看是否能找到该问题的详细信息。
Derby 现在支持内存模式，它不再被标记为实验性的。
I've been using HSQLDB in-memory for integration testing JPA/Hibernate persistence in Java. Starts pretty quickly, doesn't require any special setup.
The only issue I've seen so far with using HSQLDB with Hibernate was to do with batch size needing to be set to 0, but that might just have been related to an old version. I'll have a dig and see if I can find details of that problem.
Derby supports an in-memory mode these days, it is no longer marked experimental.
我用德比。一方面，每个单元测试大约减少了 3 行代码，因为测试后不需要关闭。但是，您需要使用可以删除和创建表的 JPA 实现，例如 EclipseLink。
Derby 还可以从文件初始化新的内存数据库，以便您可以拥有参考数据库并随时恢复到它。
不过，对于单元测试，我更喜欢在单元测试的 @Before 逻辑中创建对象，我发现它更容易，尤其是使用 JPA，因为它允许我灵活地进行重构，而不必担心底层数据库结构、其他工具（例如 DBunit）实际上依赖于静态结构，而重构意味着手动更改 DBunit XML，而不是依赖 Eclipse 的重构功能。
I use Derby. For one thing it is about 3 less lines of code per unit test since there is no need for a shutdown after the test. However, you need to use a JPA implementation that can drop and create tables such as EclipseLink.
Derby can also initialize a new in-memory database from a file so you can have a reference database and revert to it at anytime.
For unit testing though, I prefer to create my objects in my unit test's @Before logic I find it easier especially with JPA as it allows me the flexibility to do refactorings and not have to worry about the underlying database structure, other tools such as DBunit rely on practically a static structure and refactoring implies changing of the DBunit XMLs manually rather than relying on Eclipse's refactoring capabilities.