Skip to content

Commit 64c388d

Browse files
committed
Properly document avoiding false positives when testing with JPA
Prior to this commit, information regarding avoiding false positives when testing with JPA had already been added to the Testing chapter of the reference manual. However, the example did not work properly and the accompanying text mixed concepts from Hibernate and JPA. This commit fixes the @Autowired/@PersistenceContext bug, updates the text, and marks each test as @transactional in order to avoid any misinterpretation. Issue: SPR-9032
1 parent 0f6711f commit 64c388d

File tree

1 file changed

+17
-12
lines changed

1 file changed

+17
-12
lines changed

src/asciidoc/testing.adoc

Lines changed: 17 additions & 12 deletions
Original file line numberDiff line numberDiff line change
@@ -3297,29 +3297,32 @@ declarative SQL script execution with default transaction rollback semantics.
32973297
.Avoid false positives when testing ORM code
32983298
[NOTE]
32993299
====
3300-
When you test application code that manipulates the state of the Hibernate or JPA session,
3301-
make sure to __flush__ the underlying session within test methods that execute that code.
3302-
Failing to flush the underlying session can produce __false positives__: your test may
3303-
pass, but the same code throws an exception in a live, production environment. In the
3304-
following Hibernate-based example test case, one method demonstrates a false positive,
3305-
and the other method correctly exposes the results of flushing the session. Note that
3306-
this applies to any ORM frameworks that maintain an in-memory __unit of work__.
3300+
When you test application code that manipulates the state of a Hibernate session or JPA
3301+
persistence context, make sure to __flush__ the underlying unit of work within test
3302+
methods that execute that code. Failing to flush the underlying unit of work can produce
3303+
__false positives__: your test may pass, but the same code throws an exception in a live,
3304+
production environment. In the following Hibernate-based example test case, one method
3305+
demonstrates a false positive, and the other method correctly exposes the results of
3306+
flushing the session. Note that this applies to any ORM frameworks that maintain an
3307+
in-memory __unit of work__.
33073308
33083309
[source,java,indent=0]
33093310
[subs="verbatim,quotes"]
33103311
----
33113312
// ...
33123313
33133314
@Autowired
3314-
private SessionFactory sessionFactory;
3315+
SessionFactory sessionFactory;
33153316
3317+
@Transactional
33163318
@Test // no expected exception!
33173319
public void falsePositive() {
33183320
updateEntityInHibernateSession();
33193321
// False positive: an exception will be thrown once the Hibernate
33203322
// Session is finally flushed (i.e., in production code)
33213323
}
33223324
3325+
@Transactional
33233326
@Test(expected = ...)
33243327
public void updateWithSessionFlush() {
33253328
updateEntityInHibernateSession();
@@ -3337,19 +3340,21 @@ Or for JPA:
33373340
----
33383341
// ...
33393342
3340-
@Autowired
3341-
private EntityManager entityManager;
3343+
@PersistenceContext
3344+
EntityManager entityManager;
33423345
3346+
@Transactional
33433347
@Test // no expected exception!
33443348
public void falsePositive() {
3345-
updateEntityInJpaTransaction();
3349+
updateEntityInJpaPersistenceContext();
33463350
// False positive: an exception will be thrown once the JPA
33473351
// EntityManager is finally flushed (i.e., in production code)
33483352
}
33493353
3354+
@Transactional
33503355
@Test(expected = ...)
33513356
public void updateWithEntityManagerFlush() {
3352-
updateEntityInJpaTransaction();
3357+
updateEntityInJpaPersistenceContext();
33533358
// Manual flush is required to avoid false positive in test
33543359
entityManager.flush();
33553360
}

0 commit comments

Comments
 (0)