没有数据库的休眠/JPA答案

【问题标题】：Hibernate/JPA without DB没有数据库的休眠/JPA
【发布时间】：2015-10-23 05:34:20
【问题描述】：

想知道是否有可能完全摆脱对 SQL 的依赖。假设我正在编写与数据库通信的测试，这引入了管理数据库模式的需要，这非常麻烦，因为内存数据库通常与生产类型的数据库不匹配。

是否可以使用 Hibernate/JPA 并且没有下划线的 DB Schema 进行测试？

目前我知道了两种选择，我想在这里扩展我的知识，如果还有其他可能，请分享。

模拟休眠
使用假的JDBC driver

或者我应该只专注于模拟 DAO 层而不是浪费时间吗？ JPA 实体与 DB 的健全性检查完全不同。

【问题讨论】：

这毫无意义。测试应该显示问题，并且您喜欢模拟有问题的东西以忽略它们？
但是，如果您在精确的单元测试中专注于其他一些失败点怎么办。我的意思是你没有测试你需要测试一些功能的数据库，你需要有一些简单的方法来消除对数据库的依赖。在这种情况下，您需要以您期望它在正常条件下工作的方式模拟数据库行为。
切出DB是正常的吗？如果您可以在集成测试中测试所有正常条件，为什么还要测试代码并模拟一些代码？
我猜这是单元测试的目的。集成测试并不是真正的轻量级经历。在集成测试中，我认为您应该只检查与其他系统（包括数据库）的集成。对于单位来说，通常的做法是跳过外部系统的复杂性。
取决于你如何使用休眠。包括 n-m/1-n 关系！您能否将记录从 LOGIN 到 USER 到 ADDRESS 到 ORDERS 到 DELIVERYS 以获取最后一个订单的状态？它们是您应该避免的深层嵌套模拟！

标签： java hibernate unit-testing jpa jdbc

【解决方案1】：

您担心内存数据库和生产数据库之间的区别吗？但是您不担心您的两个“模拟”选项和生产之间的更大差异吗？

在我看来，任何更换生产数据库进行测试都会以某种方式产生误报。我猜想内存数据库会最好地模拟真实环境。特别是如果您使用类似 H2 的东西，它会尝试支持不同的 SQL 方言。

只要您只编写小型和封装的单元测试，模拟您的 DAO 层也可能会有所帮助。但是，一旦您开始编写集成测试，您就需要以某种方式提供数据库。

不 - 如果没有数据库架构或连接，Hibernate 将无法工作。

【讨论】：

问题更多的是单元测试，反正我现在正在调查更接近集成测试的地方。您对模拟和数据库之间的巨大区别是正确的。集成测试应该是交付代码之前的最后一个自动化点。我现在担心的是嵌入式数据库的可靠性（模仿生产数据库）肯定总是涉及一些风险（更不用说某些情况根本无法模仿）。问题是我们应该离生产多近？对我来说，我们能得到的最接近的自动方式是将容器（Docker）与真实数据库一起使用
即使你完全模仿生产数据库——你需要编写测试来检测特定于生产的错误并且稳定——没有人愿意改变一次又一次的测试只是因为生产中的数据发生了变化。甚至那些测试也不会发现所有错误。我认为您最终将获得与（某种稳定的）内存数据库一起使用的集成测试。这就是我在许多项目中所拥有的。
只是出于好奇，您究竟是如何进行集成测试的。设置环境，检查断言等。
首先我使用我自己的工具Fastnate 来创建测试数据。使用cargo，我部署并启动了一个针对H2 运行的测试服务器（使用自动模式创建或Flyway）。测试通常是 Selenium 测试，带有 page objects 和一个自己的框架（目前尚未开源），这使得编写这些页面对象和测试变得容易。
我开始这个问题的原因之一是想知道如果我将使用 hibernate 生成 SQL 会怎样，它将有什么用处，这里我们使用 Fastnate。将明确检查出来。我使用 Cargo 进行远程部署，但我缺少的是自动 env.setup。这就是我现在关注 Arquilian 和 Docker 的原因。