We extend Spring's AbstractJpaTests superclass, which is a subclass of JUnit TestCase, and then we specify the test fixture and configuration location. The test fixture will be automatically dependency-injected if we provide a setter method. We can provide any number of setter methods, but it's usually good practice to test one thing at a time. We must implement the getConfigLocations() method to return an array of the Spring configurations we want to load. Note that most of the configuration data is identical to that used in a deployed scenario, minimizing the amount of additional work needed to implement tests:

package org.bookguru;

import org.springframework.test.jpa.AbstractJpaTests;

public class BookInventorySystemTest extends AbstractJpaTests {

    private BookInventorySystem bookInventorySystem;

    public void setBookInventorySystem(
       BookInventorySystem bookInventorySystem) {
       this.bookInventorySystem = bookInventorySystem;
    }

    protected String[] getConfigLocations() {
       return new String[] {"/my/path/my-spring-config.xml"};
    }
}

Now we can add any number of test methods. These can access data by using our data access object (DAO) fixture or the jdbcTemplate and sharedEntityManager instance variables inherited from JpaTestCase as follows:

   public void testAddBook() {
     int oldBookCount = jdbcTemplate.queryForInt("SELECT COUNT(0) FROM BOOK");
     bookInventorySystem.addBook(12769356, "War and Peace", "Leo Tolstoy", Genre.FICTION);
     sharedEntityManager.flush();
     int newBookCount = jdbcTemplate.queryForInt("SELECT COUNT(0) FROM BOOK");
     assertEquals("Must have added new row in BOOK table",oldBookCount + 1, newBookCount);
   }

Here we're using JDBC queries in the same transaction to verify the correct behavior of our DAO. First we query for the number of rows in the BOOK table. Then we add a book, being sure to flush the current unit of work, using the EntityManager.flush() method. This forces the persistence provider to issue the necessary SQL update. Now we can issue another JDBC query to verify that we added an additional row. We know that our DAO doesn't merely execute without exception, but also causes the appropriate changes in our database. Those changes will be rolled back when the testAddBook() method has completed, so the changes won't be persisted or affect other tests.

With this approach, we can very quickly validate our O-R mappings and queries, as well as our Spring configuration. Very quick round trips mean that we can rapidly iterate as we enrich and map our domain model, identifying any problems early so that they take minimal time to rectify.

Best Practices
As we see from the example, most of the effort to develop JPA in Spring is in the initial configuration setup. Once we get the application context settled, the rest is just a matter of simple programming as we add more classes and beans. When working with multiple Spring/JPA projects it helps to have a template XML file that can be copied and modified as needed. If a specific architecture and pattern is commonly used, it may make sense to have a JPA-specific bean definition file and just file-include it in the application context file for every project. (Note that Spring allows a configuration to be split into any number of XML files.)

In the past, each persistence implementation had a different session API, and using a Spring template/DAO was helpful because it let Spring manage session-level resources and insulate the program from the vendor API. JPA is a standard API, so there's no longer a need to do this kind of shielding. In Spring 2.0 the entity managers are managed for you, so although Spring supports the same kind of DAO templates for JPA, they're no longer as necessary.

Spring DAOs also provide exception translation by mapping the various platform and database exceptions into a consistent Spring exception hierarchy. This provides the application with a normalized, unified exception-handling scheme, regardless of the particular database sitting underneath. In Spring 2.0 this facility is made available through the @Repository annotation, without requiring the use of DAO/template objects. Because there's currently no standard way for database exceptions to be wrapped in a JPA PersistenceException, this annotation will help applications process persistence exceptions and map them to specific causes. It's also particularly valuable for existing Spring applications that will migrate from proprietary data access APIs to JPA, or for mixing JPA and JDBC use in the same application. As in any Spring application, using Spring with JPA ensures a consistent and testable programming model, whether you're deploying to a Java EE application server, a Web container such as Tomcat, or a standalone application.

Summary
In this article we've shown how to use JPA in new or existing Spring applications to achieve standardized persistence, with little effort or change in coding style. New Spring users can begin writing applications and bring their JPA experience with them. The flexibility and loose coupling that Spring offers, with the standardization of JPA persistence, provides developers with the best of both worlds and gives them a platform that's easy to develop on and convenient to test.

The JPA Reference Implementation can be downloaded from http://otn.oracle.com/jpa, and Spring 2.0 can be downloaded from www.springframework.org/download. To learn more about using JPA with Spring, see the Spring JPA documentation at http://static.springframework.org/spring/docs/2.0.x/reference/orm.html#orm-jpa.

References
• Mike Keith and Merrick Schincariol. Pro EJB 3: Java Persistence API. Apress, 2006.
• Rob Harrob and Jan Machacek. Pro Spring. Apress, 2005.
• Rod Johnson, Juergen Hoeller, Alef Arendsen, Thomas Risberg, Colin Sampaleanu. Professional Java Development with the Spring Framework. Wrox, 2005.
• Rod Johnson, Juergen Hoeller, Alef Arendsen, Colin Sampaleanu, Rob Harrop, Thomas Risberg, Darren Davison, Dmitriy Kopylenko, Mark Pollack, Thierry Templier, Erwin Vervaet, Portia Tung, Ben Hale, Adrian Colyer, John Lewis, Costin Leau, Rick Evans, Spring Framework 2.02 Reference Documentation. 2007.