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

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

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

JavaEE与Rails和Django等框架竞争,这些框架期望开发人员针对专门用于此目的的真实数据库对其代码进行单元测试。JPA开发人员应该期望的不会更少。

您可以使用嵌入式数据库,例如。 HSQLDB 或 H2 Database

• 测试注释映射是否“正确”(如SessionFactory中所示,可以启动)
• 使用一些“小”schema.sql测试约束(例如字符串长度、外键)
• 先看一下SQL语句,找出一些奇怪的映射

和/或使用集成数据库(远程或本地构建,带有生产备份)和:

您可以使用DbUnit使用JPA测试数据库,如果您有非常复杂的查询,您可以通过这种方式测试它是否可以与真实数据库一起工作(DbUnit使用hypersonic进行测试)。然而,为测试设置数据需要一些时间,所以编写比使用mock的单元测试慢得多。这可能有点过分,但你应该试试看,看看你有多喜欢它。我认为这不值得。

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

• 那些 你
• 经常破裂的东西
• 落入 应用逻辑

JPA代码

• 如果您使用一个好的库(hibernate/toplink),那么代码已经很成熟了
• 坚持就是 业务逻辑

我想你不应该为JPA做单元测试。

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

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