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

  • The glue that holds it all together

    Apr 24 / Susanne Albinger

    Put six people in a room, provide them with post-its, a team board and a common goal and - voilá - here comes your Scrum team! High performing, creative and innovative, delivering a shippable product increment every two weeks. Sounds easy. But…

  • Team Objectbay skiing days

    Mar 17 / Camilla Franek

    Bright blue skies, snow-capped peaks and perfectly groomed slopes. The best conditions to start in our Team Objectbay skiing days.

  • Me developer, you tester

    Mar 15 / Susanne Albinger

    According to the Scrum Guide all members of a Scrum Team are Developers. However, in reality, we come across teams which are split in two: developers and testers. But isn't Agile Software Development all about teamwork? One team transforming requirements into working software. But is this really how it works?

  • What about quality? - Part II

    Feb 16 / Susanne Albinger

    It’s easy to talk about quality awareness and collective responsibility of the team. But often it’s a collection of small things and practices that add up to enable a team to deliver high quality.