Java Reference
In-Depth Information
data source, Derby will automatically start an in-memory database for the integration test,
relieving the need for an external database server to be running. Finally, a new jdbc-
connection-pool has been created specifically for the integration test for JPA entity
classes of your project. Now that the integration test has a database, let's look at configur-
ing JPA to use it.
JPA
For the integration test, you're going to test the DiscountManagerBean , which has
a dependency on membership-level data from the MembershipLevel JPA entity. JPA
needs to be able to work with the embedded Derby database when the integration test runs.
You do this by configuring /src/test/resources/META-INF/persistence.xml to use a data
source pointing to an embedded Derby database connection pool:
<jta-data-source>jdbc/chapter15-ejb-embedded</jta-data-source>
This JDBC binding is the jdbc-connection-pool you created in domain.xml spe-
cifically for this integration test. GlassFish comes with a default connection pool you could
have used for this integration test, but in general, using a default resource like this isn't ad-
visable. It's much better from an integration test perspective to create a new resource and
make sure your code can use that resource, whatever it may be. In this case you configured
GlassFish with a data source connected to an in-memory Derby database just for the integ-
ration test and now you've configured JPA to use it.
We've covered project configuration. Now let's get to the good stuff. Let's look at the in-
tegration test code itself.
15.3.2. Integration test
Let's take a look at the integration test code shown in the following listing, which uses the
embedded EJBContainer to execute your EJB.
Search WWH ::




Custom Search