Functional Testing with Arquillian

Arquillian is not only a great tool for testing inside of the container but it greatly reduces the effort for functional testing. In the following article, I'll show you how to easily use it to test a web UI of the application you're building.

Getting Started

The first three are a part of JBoss testing umbrella, the tests themselves are based on Selenium. If you are already familiar with Selenium, you'll find that Arquillian manages not only a container life cycle but it makes your live easier even w.r.t. Selenium life cycle. If Selenium is a new stuff to you, you might find that it is exactly the missing part in your tests.

Explaining the concepts of in-container and client testing

If you'd ever written an Arquillian based test, you know that it looks almost the same as others tests in the framework you're using. I prefer JUnit here, so let's make an example:

Here I've deployed a CDI bean on the server, and in the test I'm injecting the instance and asserting it is working correctly. This means that Arquillian enriches the archive, connects to the server itself, running test method inside of the container. This is actually the default behavior. This way, the JUnit test runner communicates with Arquillian, tests are executed in server JVM and results are pushed back. JUnit runner is actually a client here.

The client mode is the second mode of Arquillian testing. This way the tests are executed in the same JVM as the client is running and the testing archive is not enriched. This means you loose the possibility of retrieving objects from server JVM during testing (unless server exposes them otherwise), however Arquillian still controls deployement, undeployment and life cycle of the container.

How to activate client mode?

This is very easy. You can either mark a deployment non-testable on server, meaning Arquillian will not enrich the archive at all, or you can mark a specified method with an annotation @RunAsClient. Want an example? Here you are:

Using Arquillian Drone

That was a bit of theory. Let's get back to Arquillian Drone. Arquillian Drone is an extension written in order to manage the life cycle of other objects then servers, to be precise testing browsers.

Currently, the list of supported browsers is pretty large, let's mention SeleniumServer, Selenium, WebDriver and Arquillian Ajocado. As well as Arquillian, Arquillian Drone is pretty extensible, so if your favorite testing browser is not supported, you'll find easy to add the support.

Arquillian Drone bootstraps the tooling required for testing browsers in order to work (e.g. Selenium Server), than it creates instances of testing browser and properly disposes them after the test is finished. You only have to write the logic of the test, not to meddle with the test environment preparation.

Creating a test deployment

While running in client test mode, you have to make sure you deploy all the required bits. So, you're deployment method might be a bit more complex but there's nothing to worry about. Here is a commented example:

Here I'm enumerating all the files to illustrate the idea. However, ShrinkWrap can add a package, directory and so on, so your method will likely be shorter. I'm creating a WAR archive to be deployed named cdi-login.war. I include all classes, import.sql to populate database with data, test persistence descriptor, all the jsf pages, web and CDI bean descriptor.

As I'm using Seam 3 in the example, I'm including all the required libraries as well. Here the resolver is configured using metadata available in the pom.xml file, which defines the project. It collects dependency versions, mirrors, repositories etc. and then you can simply specify groupId and artifactId to get the Seam Solder jar library. ShrinkWrap Maven Resolver will actually search the local Maven repository and if required (and not configured otherwise) remote repositories as well and fetches Seam Solder including all required transitive dependencies. Then the jar files are packaged in WEB-INF/lib directory.

Adding a Selenium browser

As you probably noticed, I added Selenium, Selenium Server and corresponding Drone extensions to dependencies in pom.xml file. It's time to used them in the test:

That's it! Specify this as a field in the test and Arquillian Drone extension will create an instance of DefaultSelenium browser before the first client test is run and injects the instance. Here I'm using DefaultSelenium, which requires Selenium Server running. However, because I've included Arquillian Drone Extension for Selenium Server, it will be started as well and the browser connects to it automatically. Do not pollute your tests with unnecessary code, keep them simple!

Oh wait, there one more thing. I'm testing web UI but how do I know the URL of deployed application? Arquillian already has a solution:

Easy! You've just tested in the Firefox browser that your application login page works correctly.

If you liked the article, stay tuned. There is a lot more in Arquillian Drone to cover, such as configuration of the Arquillian Drone, running different browsers (Firefox, Chromium, IE, etc.); Arquillian Ajocado (Selenium on steroids with an excellent AJAX support included) or WebDriver; multiple browser instances, handling https requests, mobile devices testing and writing support for your own testing browser.

Arquillian makes integration testing a breeze. Arquillian Drone adds a great support for functional tests.