Once you started developing some integration tests, you should also think about how and where to run them.

The last part of this series is dedicated to running tests in continuous integration.

As continuous integration with a unit tests is really straight-forward, configuring integration tests to be run continuously starts to be little cumbersome.

When we designed test architecture for RichFaces framework, we have focused on ideal testing approach which would empower us to do anything we need to cover our daily jobs -

Integration Testing First Principle

Integration Testing First Principle enables you to first focus on verifying correctness, and then later paying attention to making it faster and more efficient (see Fast Feedback for Continuous Development part bellow).

Thanks to architecture of the Arquillian testing framework and its extensions, there are always options on how to improve the execution time.

Extensive Coverage in CI

Once the test suite is written, we need to run it continuously to ensure that the code is compatible with all supported browsers and containers. That’s pretty simple task when you use Arquillian.

Managing Integration Environment

As opposed to development time (when we want to achieve fast turnaround), in continuous integration we are seeking different goals – the ability to control a complete tested environment from out test suite. We can say we are managing integration environment.

Managed Containers

Once we switch tests to run in continuous integration, we can leverage Arquillian managed containers to bootstrap a container and manage its lifecycle.

Managed Browsers

Similarly, the Drone extension allows to instantiate browsers directly, without need to manually start the Selenium Server.

Once the browser session is managed, Drone itself makes sure that a browser is instantiated and destroyed as required and for a following test, you always get clean session – just as recommended by test isolation practices.

SauceLabs ~ Browsers in a Cloud

In order to use real browsers, it is usually necessary to invest in your test infrastructure.

Fortunately even this initial infrastructure investment can be avoided by using cloud browser-providers like SauceLabs.

Drone supports this out-sourcing-to-a-cloud shift and simplifies it to a simple configuration switch.

Fast Feedback for Continuous Development

Once we have configured tests to be run against real implementations while following Integration Testing First Principle, it is time to make it really useful by configuring it to deliver fast feedback.

In order to guard against regressions which could be introduced by code changes, we should run tests continuously after each commit.

This could be very resource-consuming since we have so far written just real browser tests.

PhantomJS ~ Mock Browser

Fortunately there are browsers which can run WebDriver-based tests headlessly, without any external dependencies and faster then real browsers.

And that’s where Arquillian and Drone shine again: you can simply switch from real browsers to a mocked browser.

There are currently two mock browsers with support for WebDriver:

• PhantomJS – a headless fork of QtWebKit (similar to Chrome/V8 engine)
• HtmlUnit – an artifical engine based on Rhino

Conclusion

When we put all the pieces together, we get the greatness from both worlds – we are testing on the real browsers and the real containers during full-fledge testing sessions, but we also get as fast feedback as possible with our integration tests running on the mock browsers.

In this series I wanted to show you that testing JSF can be really simple with employing right tools for the job. Arquillian gives us everything we need:

• extensive coverage
• ability to run in continous integration
• effective development and debugging workflows

At the end, you are provided with incredibly useful set of technologies which guards your implementation, increases the trust in a code and, what’s most important, it makes the testing fun again!