Java EE7 and Maven project for newbies – part 6

Paris ApostolopoulosJune 25th, 2014Last Updated: June 24th, 2014

1 78 4 minutes read

Resuming from the previous parts

Part #1, Part #2, Part #3, Part #4, Part #5

In the previous post (part 5), we discovered how we can unit test using Arquillian, our EJB services, deploying them in a ‘real’ instance of Wildfly8.1 application server. Extending the previous example we will add some more configuration and code, so that we can add unit tests that involve our JPA2 Entities. Creating, saving and retrieving information from the database is a very fundamental task of any JavaEE application. We need to make sure that our domain model and the logic coded on top of it is as much tested as possible. I am going to use the ‘simplest‘ form of configuration and related libraries. Since we already test towards Wildfly 8.1, we will be using an internal H2 in-memory database that is bundled with the server, and the related ExampleDS datasource.

Watch out, this is just for testing and demo, in real life you will want to test under a heavy production based RDBMS, the difference that you should :

create a test DB schema in your DB server (e.g Oracle, MySQL, DB2…)
Add appropriate Datasource configuration to the application server, so that it connects to to the above DB server.

We have already setup Arquillian, and is already leveraging the capabilities of a standalone Wildfly 8.1 application server. In the previous post (part 5), we have been a simple Stateless EJB , that was not retrieving or saving information on the database. On the sample-domain module we have already defined a simple JPA2 Entity Bean. We would like to test some basic stuff, like save the entity on a database, retrieving the entity etc. It is a common pattern even nowdays, for many projects, to create stateless sessions beans that are actually implementing this code for each entity. You might have heard of them as ‘DAO’ classes. In our case there is no DAO implementation but the same principles would apply.

Defining a test-persistence.xml

As we have already defined a standard persistence.xml under the sample-domain module (jar), that is configuring actually our Entity Manager, we need a similar confinguration. Eventually a very similar persistence xml but this time is going to be placed in the /src/test/resources folder, because it is going to cofigure for us, an Entity Manager that is going to be picked during our tests, from our Arquillian/Wildfly test combo.

This is how it looks:

   <?xml version="1.0" encoding="UTF-8"?>
    <persistence version="2.0" xmlns="http://java.sun.com/xml/ns/persistence"
                xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
                xsi:schemaLocation="
           http://java.sun.com/xml/ns/persistence
           http://java.sun.com/xml/ns/persistence/persistence_2_0.xsd">
        <persistence-unit name="test">
            <jta-data-source>java:jboss/datasources/ExampleDS</jta-data-source>
            <properties>
                    <property name="hibernate.hbm2ddl.auto" value="create-drop"/>
                    <property name="hibernate.show_sql" value="true"/>
                    <property name="hibernate.format_sql" value="true"/>
                    <property name="hibernate.dialect" value="org.hibernate.dialect.H2Dialect"/>
            </properties>
        </persistence-unit>
    </persistence>

Some notes on the above file:

We are defining the ExampleDatasource that is pre-configured on Wildly 8.1
WildFly 8.1 comes bundled with Hibernate 4.x, so we are using ‘safely’ properties of Hibernate configuration.
We are using the ‘create-drop‘ strategy so that means that every time we run the test (s), hibernate is going to drop the tables in the underlying database and recreate them. That will help us in cases where we are experimenting and we are constantly changing our domain model.
The emb. database that Wildly offers is H2, so we are configuring Hibernate to use this ‘dialect‘.

Creating an Arquillian Test

This is how our test looks like (you can check out the source on the git link at the end of the post):

Some notes on the above code:

Point 0: This is one of the most important parts of every Arquillian based test. This is where we create the in memory ‘war’, our deploy-able that will contain the classes under test and any other resources needed by the supporting frameworks. All the wiring is done using an Arquillian based framework called ShrinkWrap. In our case the ‘createDeployment‘ method, will package our single JPA entity called ‘User’ and a persistence.xml file, which is actually the test-persistence.xml under our test resources , configuring an Entity Manager that is working with the default Wildly Datasource.

Point 1: This is a special annotation, very handy on more complex tests, by using this annotation we are actually injecting by default JTA (transactional) support on our test methods, in this particular test is not heavy used. Make note of the ROLLBACK setting. It indicates that whatever this test method does within a transaction at the end all the insertions/deletes/updates are going to be rollbacked, so we leave no garbage behind.

Point 2: We need to annotate our test with the appropriate RunWith annotation, indicating that we want the Junit/Arquillian mechanism enabled.

Point 3: We are injecting an entity manager, like we would have done in a regular EJB /resource. The name of the persistence manager must much with the one defined in the test-persistence.xml, so watch out.

Point 4: The @Before Annotation is indicating that the init() method, will run before every test. This is a great place to initialize any data,and prepare our test domain environment.

Point 5: As you can see within the init() method, we are persisting a User entity, similar to what we would have done in our product / real code!

Point 6: The actual test method, we are trying to query for the object, persisted later on.

Finally

The fact that we have already configured and prepared our project structure and configuration in order to use Arquillian, is actually the most important thing. Once you have the basic blocks ready, then it is a matter of writting more test and experimenting with your code. Right click on the test and as you can see, we have the green light of success, a clear pass. Happy testing!