JPA的单元测试案例值得吗？无论如何它只是要访问DB，为什么我们需要它？

Question

JPA的单元测试案例值得吗？无论如何它只是要访问DB，为什么我们需要它？

Answer 1

到目前为止，我不同意大多数答案。对于大多数企业应用程序，大多数业务逻辑都嵌入在数据库查询中，如果您使用JPA，则大部分都在JPQL中，而有些可能非常复杂。这是您正在编写的代码，因此您应该对其进行测试。

如果查询很简单 - 没有复杂的连接或标准 - 那么它并不是一个问题，但根据我的经验，这些应用程序很少见，你可能不需要像JPA那样强大的东西来构建它们。您将为那些天真地试图让其持久层保持“业务逻辑”的应用程序的可伸缩性付出代价。

对于大多数JPA应用程序而言，测试必须在容器外部运行，作为正常，持续集成构建的一部分。典型的方法是使用内存数据库，如HSQLDB或H2。

Java EE与Rails和Django等框架竞争，希望开发人员能够针对专门为此目的而专用的真实数据库对其代码进行单元测试。 JPA开发人员应该期待不会少。

Answer 2

您可以使用嵌入式数据库，例如HSQLDB或H2 Database和：

• 测试注释映射是否“正确”（如可以启动SessionFactory）
• 使用一些“小”schema.sql来测试约束（例如字符串长度，外键）
• 尽早查看SQL语句以发现一些奇怪的映射

和/或使用集成数据库（远程或本地构建与生产中的备份）和：

• 进行一些性能或实际数据测试

Answer 3

我从未对JPA实体进行过单元测试。我对业务逻辑进行单元测试，你可以直接使用JPA实体/查询，也可以模拟查询。

任何合理的IDE都将验证JPA模型，以便所有表名和列名都正确。一旦完成，还有什么可做的？单元测试查询的问题在于，您必须能够期望某些数据验证测试，并且我从未成为仅仅为了通过测试而创建虚假数据的粉丝。

Answer 4

你可以使用DbUnit来测试数据库与JPA，如果你有非常复杂的查询，你可以测试它是否适用于真正的数据库（dbunit使用hypersonic进行测试）。但是，设置数据以进行测试需要一些时间，因此写入比使用模拟的单元测试要慢得多。它可能有点矫枉过正，但你应该尝试一下，看看你喜欢它。我觉得它不值得。

Answer 5

我对单元测试我工作的应用程序的经验促使我最初创建访问我们的ORM的“单元测试”，要求数据库在后台运行。显然，这比你真正想要进行单元测试更重要，设置/拆卸需要通过ORM创建和删除数据以及访问数据库，这实际上是一个集成测试，但没有理由不这样做。我这样做是因为我们在数据库中有很多逻辑，这是一个非常简单的方法来使用每个人都能理解的代码来访问它，在你的情况下，我想你需要问一下你是否有自己的代码通过这样做来测试。

Answer 6

通常建议进行单元测试

• 你写的东西（不是库/框架）
• 可能经常破坏的事情
• 属于应用程序逻辑代码的内容

JPA代码

• 是由其他人写的而不是你
• 如果您使用好的库（hibernate / toplink），代码已经成熟
• 持久性 NOT 业务逻辑

恕我直言，你不应该为JPA进行单元测试。 对于极端情况，请使用已提及的DbUnit。