Arquillian with Wildfly 8

I’ve recently been looking into Arquillian and have been asked how it can be made to work with Wildfly. In this post I’ll attempt to layout a sample project outlining the steps needed to use the wildfly container for arquillian integration testing. Stick with me this post could get pretty long with code examples.

First lets set up a simple project with a Stateful EJB and a simple Entity. I’m assuming a basic familiarity with maven and you can create a default maven project. I’ll be including snippets from the pom to show configuration and dependencies.

This picture shows the basic project layout and files involved in this simple test project. We will talk about most of these in detail.
eclipse project layout

First up we will need something to test so here is a really simple Person Entity.

And a small EJB with two methods which we want to test.

Now we need to include a number of xml files and also configure our pom.xml

arquillian.xml

The first file is arquillian.xml here we define our container (Wildfly). In this case we have only one defined but you can define more than one and select based on the qualifier. In order to use Wildfly you need to define your “jbossHome” which is where your wildfly application server is installed. Yes thats right you do actually need to download and install a wildfly instance which can be used by your unit tests. In my opinion this should be fully embedded and thus standalone but apparently this is by design. see: https://community.jboss.org/message/855086#855086. Briefly looking at the EmbeddedContainerConfiguration modulePath shouldn’t be needed as it should be created based on jbossHome but I was unable to make the tests run without explicitly defining it here.

wildfly-ds.xml

For unit testing its often easier to use an in memory database. We can define our own datasource by including a -ds.xml file in our Shrinkwrap war. In this case we are using an H2 database.

test-persistence.xml

our application persistence.xml file wont be of much use to us as we need to point to a different database which is configured differently so instead we include this test persistence.xml file. Its all pretty standard and just references the above datasource.

pom.xml

The last configuration needed is to update our pom.xml with all the dependencies needed for testing. I’ve included the full pom file here as a reference.

The key bits to note here are the systemPropertyVariables (lines 99 – 101) which configures the log manager for wildfly.

MyBeanTest.java

Finally we need our jUnit test class. If you are using TestNG the process is similar.

Whats going on?

If you have used arquillian then the above test wont look too foreign but just in case lets go over whats happening.

Line 13: we tell jUnit to use the Arquillian test runner. This is what makes all the magic work.

Lines 16 – 20: Using Arquillian lets us inject beans directly into our unit tests.

Lines 22 – 29: Shrinkwrap is used to create a very small deployable war file containing only the bits we want to test. Here we are including all the java classes in the package containing MyBean.java, we include an empty beans.xml to indicate that this is a CDI project, we include our test persistence.xml but rename it and place it in the META-INF folder – this lets us use another datasource for testing. We also include wildfly-ds.xml which is our in memory h2 datasource.

Lines 31 – 36: is just a normal unit test.

One more trick

If you want to run your tests in eclipse you will probably see an error telling you you must configure a log manager. The easiest way I’ve found to get round this is to add a default VM argument to your jdk. To do this go to preferences -> Java -> installed JREs and paste -Djava.util.logging.manager=org.jboss.logmanager.LogManager into the default VM arguments line.

eclipsedefaultvmarguments

Success

Now with any luck if you run your test it should be green.

greentest

 

Leave a Reply