Turbo Boost for Arquillian Tests

Accelerate your integration tests significantly!

Integrationstests with Arquillian

Arquillian is an Open Source test framework for Java enterprise applications which was developed by the JBoss Community and is available in version 1.0.3. Arquillian can be used for developing integration tests for Java EE applications; the implementation is performed inside a container (e.g. JBoss Application Server). Other features of Arquillian are described on its website in more detail.

In this article we would like to show you how to reduce the execution time of our Arquillian tests to a minimum with a few tricks. If somebody wants to become familiar with the functionality of Arquillian at first, we recommend the official guide.

Automated tests must be fast!

The faster our automated tests run, the earlier we receive feedback whether our code is still alright. If the project size grows, the number of tests as well as their execution time will increase. Consequently you often arrive at the point where the tests take too long to execute them continuously and to ensure that the previously added code does not impede the current functionality.

If you practice Continuous Integration, you want to trigger an automatic build after every commit that should also perform all of the tests. In this case quick feedback is desirable. Who wants to wait one hour or even longer to come to know whether the regression tests still pass after the commit? This cannot be called “continuous” anymore and the focus on functioning tests at all levels moves into the background – the tests are executed considerably rarer; the developers receive the feedback even later; it is difficult to find the appropriate changeset for the failed tests etc.

Therefore, the principal target is that all tests pass in only a few minutes and not to slow down our automated build unnecessarily, which is also recommended by our 10 minutes build in Extreme Programming. There are various general approaches, but also tool specific optimization measures can be used – the following example is aimed at Arquillian tests.

10 minutes for approximately 180 integration tests?

As an example for illustration I would like to use a Java EE 6 project which has recently been developed by us. We already noticed very early that the integration tests take an enormous amount of time – the entire execution time of around 180 tests was over ten minutes! Due to the fact that the number of tests would be even higher in case of ongoing project progress, an optimization was urgently needed.

The reason for the long execution time was quickly found: Prior to every Arquillian test, a package created with ShrinkWrap is put out which contains the respective test class including all dependencies. Now the problem is that Arquillian does not de facto support the execution of this deployment on the basis of test classes or even test suites. The respective feature request (ARQ-197) has already existed since 2010(!); however, it was only promised for version 2.0.0.CR1 whose release date is still up in the air.

The Turbo Boost: "Brute Force Arquillian"

The project manager of Arquillian, Aslak Knutsen, also noticed that the lack of the features mentioned above poses a problem. Therefore he implemented a workaround by which the mechanism of the one-time deployment can be realized for several tests. He calls this solution Brute Force Arquillian (if you have a look at the source, you will know why) and provides the source code as well as the instructions for free.

By means of this optimization we succeeded in reducing the execution time of the tests to 70 seconds – this is approximately a tenth of the original duration! Now the execution time increases only very slowly with a higher number of tests as the execution of one Arquillian test only takes from 10 to 50 milliseconds (including the purge of the database and the following import of required data into the database)

02 May

Build Notification @ Objectbay

By Daniel Haslinger

At Objectbay, we live Continuous Integration! In this article we show you how we deal with broken builds and how you can implement our approaches in your organisation.

22 Apr

Bollywood Scrum

By Andreas Wintersteiger

You’ve already implemented Scrum some time ago. Your teams work with a “Backlog” and plan “Sprints” at intervals of two weeks? You hang up nice charts, have a task board, and meet every day at 9:30, and every member tells the others, what he has done yesterday, what he is going to do today, and that there are “no impediments”?


Latest Articles

  • Dysfunctions of A Team - 3

    Jun 06 / Alessandro Grimaldi

    Lack of commitment is the third dysfunction of a team whose roots are to be found in the Illusive desire of holding up an artificial harmony as described in my previously published article of May 10, 2016. Patrick Lencioni defines “Lack of Commitment” in his book “The Five Dysfunctions of a Team - A Leadership Fable”...

  • Dysfunction of A Team - 2

    May 10 / Alessandro Grimaldi

    On January 12, 2016 I wrote the first article about dysfunctions of a team, in particular about the absence of trust, its impact on a team and ways to overcome it. Along with the absence of trust comes the illusive desire to maintain an artificial harmony that hinders the occurrence of productive, ideological conflict. Fear of Conflict - The 2nd Dysfunction ...

  • Why Java?

    Mar 31 / Hannes Bauer

    Your investment in software based on Java EE is much safer than in any other technology stack, just because it's standard. Java is the world's most used programming language and ecosystem, multiple technology vendors support the standards.

  • Dysfunctions of A Team - 1

    Jan 12 / Alessandro Grimaldi

    Do optimal Scrum teams really exist? Teams who suffer from human misbehavior are dysfunctional and no more than an ideal image of providing together a performance. Teamwork rarely works really well. Instead, people are hiding information as advantage, maneuvering, pacting, perhaps even sabotaging and intriguing. The 5 most common human misbehaviors which can fail teams, ...