0

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

4

6 回答 6

4

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

如果查询很简单——没有复杂的连接或条件——那么就没有那么大的问题了，但根据我的经验，这些应用程序很少见，而且您可能不需要像 JPA 那样强大的东西来构建它们。对于那些天真地试图保持其持久层不受“业务逻辑”影响的应用程序，您将为可扩展性付费。

对于大多数 JPA 应用程序，测试在容器外部运行是您正常、持续集成构建的一部分，这一点至关重要。典型的方法是使用内存数据库，如 HSQLDB 或 H2。

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

于 2009-02-15T06:19:45.673 回答
1

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

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

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

  • 进行一些性能或真实数据测试
于 2009-02-04T01:01:43.200 回答
0

我从来没有为 JPA 实体做过单元测试。我对业务逻辑进行单元测试，您可以直接使用 JPA 实体/查询，也可以模拟查询。

任何合理的 IDE 都会验证 JPA 模型，以确保所有表名和列名都是正确的。一旦完成，还有什么可做的？单元测试查询的问题是您必须能够期望某些数据来验证测试，而我从来都不喜欢为了通过测试而创建假数据。

于 2009-01-17T01:38:31.613 回答
0

您可以使用 DbUnit 通过 JPA 测试数据库，如果您有非常复杂的查询，那么您可以测试它是否适用于真实的 db（dbunit 使用超音速进行测试）。然而，设置测试数据需要一些时间，因此它的编写速度比使用模拟的单元测试要慢得多。这可能是矫枉过正，但你应该尝试一下，看看你喜欢它。我认为它不值得。

于 2009-01-17T02:20:14.383 回答
0

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

于 2009-01-31T10:28:35.117 回答
0

单元测试通常用于

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

JPA 代码

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

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

于 2009-02-10T22:07:32.800 回答