Java Reference
In-Depth Information
In you see member data being inserted into the database, and in you see the same
thing for membership-level data. Both of these actions are performed in a method annot-
ated with JUnit
@Before
. When JUnit hands off responsibility for running the test to Ar-
quillian, Arquillian interrupts the standard JUnit test lifecycle to call its own
@Deploy-
ment
method. Now that that's complete, Arquillian needs to come back to the JUnit test
lifecycle, and this is what you see here. You need the database filled with the correct data
to run the integration tests. You do this for member data and for membership-level data
in the
@Before
method. At this point, the embedded container is up, dependencies have
been injected into the test, and data has been added to the database (so you already know
the embedded
EJBContainer
is working). Now all you have to do is run the tests.
The method annotated with
@Test
is
userGetsGoldDiscount()
. From the name of
this test, it's obvious what the integration test will be trying to verify; given the data in the
database for a gold-level member, will the member actually get the gold-level discount ex-
pected? In you call the
findDiscount(member)
method. Remember that this is a
real EJB method call that will use real JPA classes to talk to a real database. The integra-
tion test mimics the real environment as closely as it can to make sure the integration of all
these technologies is working properly. After the
findDiscount(member)
method is
called, the response is asserted against the expected value . If all goes well, you'll get the
green bar for the integration test.
That's it! You've successfully performed an integration test of the
chapter15-ejb
EJBs
using Arquillian. In this example you showed only a single
@Test
method that covers
only one use case that the
findDiscount(member)
method handles. The question is
whether you should add more
@Test
methods to handle the other test cases. Answering
this question really brings up the passions of the testing community. In general, the answer
would be no, because that isn't the responsibility of the integration test. A unit test should
handle all possible inputs and outputs and verify that the business logic is working prop-
erly. An integration test should verify that the integration of all the technologies (for ex-
ample, EJB, JPA, and Database) is working properly. There are different kinds of tests with
different goals, and you'll need to decide for yourself what works best for your projects in
your organization.
This finishes our coverage of testing EJBs. We've covered how to unit test your EJB using
JUnit and Mockito. We've also covered how you may integration test your EJBs, either by
using the embedded
EJBContainer
directly or by using a integration testing tool such
