The latest expert opinions, articles, and guides for the Java professional.

Release Management for Enterprises

4. Control Quality with Testing using Arquillian and Selenium

Quality is paramount. Regression bugs easily find their way in the codebase as you grow its featureset. Manually spotting them is complicated and time-consuming. Unit testing is a major topic on its own that RebelLabs has covered before, so we won’t go into too much detail here. Needless to say, it’s something you want to use.

Run Unit Tests with Maven

As a best practice, developers should have automatic tests for every project. It takes minimal effort to write, but has our backs when we play around with code changes.

Fortunately for us, most build tools provide means to package and execute tests. For example, if you used Maven to run builds, typing ‘mvn test’ in your project home will generate a build and execute unit tests.

Now let’s incorporate automated test execution into our pipeline. Go to your Bamboo plan.

1. Add a stage called “Test”

2. Add a job “Unit” to stage “Test”

3. Add a Maven step task to execute the “clean test” command. Mark this job to indicate that it contains test results, so it will fail if there are none, and Save.


Awesome. Now click the run button and watch Bamboo check out your source code, build it and execute unit tests for your project.

Integration Tests with Arquillian

Unit tests are great for testing individual modules, but we need integration tests to ensure these individual components play well together. We’ll explore a couple options here.

Let’s start with Arquillian, a framework from JBoss that injects tests into a proper container and runs them inside it.

Arquillian literally brings execution environments to tests. Go to your project and add dependencies to the Maven pom.xml, it will enable running JUnit tests with Arquillian:

   groupId: org.jboss.arquillian.junit
   artifactId: arquillian-junit-container
   groupId: org.jboss.arquillian.container
   artifactId: arquillian-weld-ee-embedded-1.1
   groupId: org.jboss.weld
   artifactId: weld-core

Now components of your system can use dependency injection with CDI’s @Inject annotation. And they will be properly initialized in the container!

Change your test declaration to run with Arquillian:

public class MyTest {

Add a method marked with @Deployment: to specify which resources should be packaged when deploying to container. Run tests as usually with: mvn test.

To improve readability of test results separate unit tests from integration tests. Make arquillian run tests on mvn integration-tests phase or use a maven profile to separate them from other tests.

Hooking up Integration Tests in Bamboo

Now let’s hook up these integration tests to your Bamboo plan just like we did with unit tests job (NB: If you need to, please see the previous section for the screenshots):

  •  Add a job called “Integration” to stage “Test”

  •  Add a Maven step task to execute the clean integration-test command

Sweet! Now these two jobs run your unit and integration tests, and ensure that your application’s functionality stays true.

But hey, why not run integration tests on a real application server? What is really cool about Arquillian tests is that you can run them on a real application server with the same amount of effort. You just need to change a couple of dependencies. We chose to run tests on JBoss AS 7 for this example. Here is what you need:

  • jboss-javaee-6.0 – api specification

  • jboss-as-arquillian-container-remote – Jboss specific arquillian adaptor

  • arquillian-protocol-servlet – to communicate with remote JBoss process

That’s it! Now when we start a JBoss AS instance to run tests, our deployments will be injected into the real application server! You can even make it work with application servers running on remote machines. Simply add adapters for other servers and test your products on every platform you support.

Acceptance Tests with Selenium

We’re not done with tests … yet! Let’s add some end-to-end tests to test whether the flow of your application is performing as designed from start to finish. We’ll use Selenium, a widely-used framework to programmatically control web-browsers, to simulate a user and ensure that our product responds correctly to UI interactions.

You’ll need to add a number of dependencies:

  • arquillian-drone-impl

  • arquillian-drone-selenium

  • arquillian-drone-selenium-server

  • selenium-java

  • selenium-server

The Arquillian drone is a framework to manage the browser lifecycle so all you need to focus on is writing the tests themselves. Now, your tests can use Selenium API to specify what a user would do:

browser.type("id=username", "liverebel");
browser.type("id=password", "4eva");"id=login");
assertTrue("Nothing works! Not even login!", browser.isTextPresent("Welcome!"));

These four simple lines of code will simulate clicking around in the browser, typing text into a form and test whether a user is able to successfully log into your deployed application to receive the “Welcome!” message.

If this seems hard and complicated, remember for a moment that we agreed that making a pipeline would require collaboration with development team. They know how to run tests and in general are the most interested in getting a continuous feedback about the current development version.

We recommend that you run these tests run when a separate Maven profile, named for example “acceptance”, is enabled. It will separate them from other types of tests. You can do a step further and make several profiles to test different browsers or application server types.

Hooking up a Acceptance Tests in Bamboo

Just like we did with the unit tests and integration tests, let’s incorporate this end-to-end UI acceptance test into our Bamboo plan:

  •  Add a job called “Acceptance” to stage “Test”

  •  Add a Maven step task to execute the “clean test -Pacceptance” command

Now our stage “Test” contains 3 jobs that run unit, integration and acceptance tests respectively. When your tests cover all the important functions of your application, you can be certain that it is fairly free of bugs and is of good quality, before allowing it to travel further along the release pipeline.


Do you recall from Step 0 where we suggested that test results are indeed deliverables? They help us decide whether to roll out the release or not. At this point you can make another stage in the Bamboo plan to archive test results in the artifact repository.


Responses (2)

  1. Avatar  


    August 22, 2013 @ 1:58 pm

    Was there a reason behind using GitHub, instead of Atlassian’s Stash product?

  2. Avatar  

    Oliver White

    August 26, 2013 @ 7:02 am

    Not in particular, we just wanted to experiment with other tools out there and expose our readers to as many different technology companies as possible. We also produced a similar report last year with free or OSS tools entitled “Pragmatic Continuous Delivery with Jenkins, Nexus and LiveRebel” — check it out:

RSS feed for comments on this post.

Leave a comment