How to run parameterized junit arquillian tests

by poolik

Arquillian is an awesome tool for testing java apps written in the EE ecosystem. It allows you to run your tests within the actual application server, so you don’t have to mock your services or dependencies. Instead you use them exactly the same way you use them within your application. For more information about Arquillian please see this awesome getting started guide.

However, because of the way Arquillian works with JUnit (as a special runner) you cannot use many JUnit’s advanced features (there can only be one @RunWith annotation). Namely I was missing the ability to run parameterized tests or theories. After a quick search I found this gist – an example how to achieve the parameterized test behaviour in Arquillian via JUnit Rules.

JUnit Rules are special inceptors for your tests that allow you to redefine the behaviour of every @Test method. For more info and examples of @Rule usage see the JUnit Rules wiki guide.

The rule written by Aslak Knutsen works, but I found that it doesn’t support running my tests in client mode. As an example let’s say I wanted to test that some resources in my application are properly gzipped. To test this, I would list the resource files I want to test and then iterate over them. Make a request and see if the response is gzipped – sounds like a parametrized test.

To achieve this I rewrote Aslaks gist adding support for client mode and a nice way to declare where to inject parameters with the @Parameter annotation. You can find the full gist here, but let’s just quickly see what the end result looks like:


I think this is about as simple as it can get. The ParameterRule class gets invoked before each test method invocation. It then figures out whether we intended the test methods to be run in container or as a client. Depending on which you configured (via the testable parameter) it will inject the defined parameters one by one to the field annotated with @Parameter and run the test method with that parameter.

The only drawback with this solution is that the multiple test executions with different parameters are reported as one, but otherwise I think it’s a pretty nice way to achieve the required behaviour.