This post is about aliens. There will be new X-Files series. I watched some episodes, I’m not a big fan, but this show had its good sides. In Java aliens are present from some time, I don’t even remember when they landed. My first 3-rd degree encounter with them was around 2012. The alien that I saw looked a little bit like this


Arquillian (difficult name – but hey ! his an alien) is a platform for running Java EE components tests inside Java EE, CDI and Servlet containers. There are modules available for functional testing (Graphene / Drone), persistance layer testing and other. It can manage embedded containers, manage containers by itself, it can attach to external container started in some other way. Arquillian creates deployment archives for this containers and provides us with test runners. Available containers are listed in the modules section of Arquillian home page and in the reference guide. Modules section is more up to date, but it does not provide complete guide on how to setup test environment.

Arquillian lets you test different component types depending on container used, but most of the time you will probably test with full Java EE Container or Servlet Container. Arquillian can even download server by maven resources plugin, it will be useful for the demo now. I think I may reuse this setup for next posts about Java EE, but then I will use external Wildfly or some other Java EE server. I would like to build a knowledge management application in Java EE using Domain Driven Design.

Why would I need module testing ? I prefer to test integrated modules as a lot of bugs is related to errors in cooperation between modules. With rigorous unit testing (that is test that test single unit of code) and design it may be possible to provide comparable quality, after all every component has provides API that can be tested. But then again if we plan and provide test in unit test that covers case component will throw InvalidArgumentException will not prepare us for actually handling this exception in client components.. Yes, it can be handled in client component (or some higher level component up the call stack), but you also must detect cases where you forgot to take care of it – and this is where rigorous unit testing comes in to consideration. In real life projects it’s sometimes not so easy. After all software development is about providing software that provides business value and required quality and architecture metrics. Having this in mind I prefer to create automated functional (e2e) test (always for not trivial projects) and then test that are more module or unit tests depending on component. Testing integrated code often requires container – like Spring or Java EE container. This is where Arquillian comes in.

Getting back to our alien – setting up Arquillian is not easy. My setup is not the most up to date one. I tried to update it, spend some time fighting with Wildfly / Aruqillian configuration and decided that it is not the most important thing to use Arquillian Universe instead of older setup. After all we will be using Wildfly 8.1 and Java EE 7 – good enough 😉

First thing is to set up maven configuration:

1. Set up integration test plugin

Important detail here is to setup system properties variables as these will be used by Arquillian and passed to Wildfly. We will us standalone-full.xml so that we can test API’s like JMS that aren’t available in standalone config.

2. Download and configure Wildfly

3. Dependencies

Here we have setup in parent pom – notice

  • jboss-javaee-all-7.0 dependency – we do not use the javaee-api dendency as it contains only API withou implementation (look at warning here)
  • arquillian-bom – this pom contains all dependencies required for Arquillian, we import is so that we do not have to specify full dependency configuration ourselves

and core module:

Now we can setup Wildfly in standalone-full.xml. Important part is overwriting port values here – originally http management port conflicts with NVidia application on Windows. We may also overwrite http port (but we are not really required to do so)

Finally setup in  arquillian.xml, a configuration file used by Arquillian. We just need to tell Arquillian what is the number of management port (setup in standalone-full.xml)

In order to create test we need to specify deployment that Arquillian will work with. We do it using ShrinkWrap module:

Now we are ready to do Java EE module testing:

Example code at github.

Have a nice day 😉