Adding Integration Tests to Your Personal CI Server

DZone 's Guide to

Adding Integration Tests to Your Personal CI Server

As an individual developer, I want to have my code compiled and deployed even if it fails tests, which is something a personal CI server can accomodate.

· DevOps Zone ·
Free Resource

In a previous article, I stepped you through the process of building a basic personal CI server with Jenkins. We got to a point where we could build a Java Web application with Gradle and deploy it to WildFly. For those who are impatient, the exported VirtualBox image with Jenkins configured using these steps is available here. The username and password combination for Linux, Jenkins, and WildFly is myci and password.

Integration tests are something that I find myself ignoring until I am almost ready to submit a pull request, and sometimes not even then. By their very nature, integration tests can take a reasonable amount of time to run, and I don’t usually have the patience to sit around and watch a script click through my web app.

With a personal CI server, this pain goes away. We can configure the tests to run upon our code being committed without the hassle of failing tests breaking builds as would be expected on a shared CI server.

Configuring Tests

For this example, I’m going to configure an Iridium end-to-end test to be run once a feature branch is built and deployed.

First, go to this link and download the latest IridiumApplicationTesting.jar file. Save this under the /opt directory.

Now open up the configuration for the Sample_Project_Build item and scroll down to the Add Build Step button. Click this and select Execute shell. In the Command text area, add the following script:

if [ "${BRANCH_NAME}" == "master" ]; then

java \
  -DappURLOverride=http://localhost:8080/gradle-sample-project${context_suffix} \
  -DtestSource=./test/endtoend.feature \
  -DtestDestination=PhantomJS \
  -DsaveReportsInHomeDir=false \
  -jar /opt/IridiumApplicationTesting.jar

Note that this script assumes that you have followed the instructions in Supporting Feature Branch Deployments in Your Personal CI Server to rename WAR files according to the feature branch name.

This will launch Iridium with the Cucumber feature script included as part of the Git repo and will run the tests in the headless PhantomJS browser. The results of this test will be saved in a JUnit report file called MergedReport.xml.

To parse this JUnit file, click the Add Post-Build Action button and select the Publish JUnit test result report option. Set the Test report XMLs field to **/MergedReport.xml and set the Health report amplification factor to zero.

Image title

These new steps will result in an end-to-end test being run with each commit but will not break the build if any tests fail. Broken tests are expected during development and I don’t really consider them to be errors. However, if you would like Jenkins to report any test failures, set the Health report amplification factor to one.

Now, end-to-end integration tests are run with every commit without developers having to think about manually triggering them and without any interruption to the development flow. This is in contrast to a shared CI server, which will typically break the build when tests like this fail, which I personally find to be a jarring intrusion into my development flow (which involves a quick succession of small changes that eventually results in a codebase that passes the tests), which is all the more reason for developers to maintain their own personal CI server that works with their development style.

continuous integration, devops, software testing

Published at DZone with permission of Matthew Casperson , DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}