Jenkins Integration using Headless browser

Sometimes it’s really useful to be able to run tests without supervision. There are many situations where this comes in handy, and the typical case is in a continuous integration or continuous delivery pipeline. For user interface testing this can be especially difficult, as it relies on Javascript being executed in the browser. As the pipeline usually relies on Cloud servers without screens, this requires a headless browser, such as PhantomJS. As PhantomJS has been covered in many articles, I will show how this can be done using the npm package npm-headless-chromium (Chromium browser and Xvfb), which can be found here. The example focuses on how to do this using the build server Jenkins and Boozang test service, but it should be easily generalized to other CI servers and test tools.

 

 

Boozang test tool modifications

[This section is only useful for Boozang users and can be skipped for other test integrations].

As we were doing development on our Boozang test tool, we realized quite quickly it would be ideal if we could use our own tool to test the various user interfaces of our platform. The ideal case would be if every time we pushed a code update into version control (in our case Github), Jenkins would check out our code, run all unit and integration tests, and test the user interfaces using the Boozang test tool.

This requires a Jenkins pipeline implementation which is more-or-less standard (might be a separate blog post on that in the future), and a Jenkins build job that kicks off a headless browser that can run through the test and somehow return the results to Jenkins. In the case of failure, a notification should be sent to the developers. In the case of success, Jenkins should allow for manual promotion into staging and into production.

The first step was to enable automatic authorization for Jenkins user in the Boozang tool. For security considerations, the recommended way is to add a user to your project with only execute permissions and add user and password to the Boozang html snippet in the following way:


<script type='text/javascript' src='//api.boozang.com/ide?id=your-project-api-key></script>
<script>
username="jenkins@yourdomain.com";
password="xxxxxxxxxxx";
</script>


The next thing was we made sure that tests could be triggered directly from the URL in the Boozang test tool. This is done by appending “/run” to the URL. We also made sure the report was written in HTML to the console log. As run-headless-chromium can capture the console log, it allows us to grab this result and write to a file. The modified run-headless-chromium can be found here.

Jenkins configuration

In order to get started in Jenkins, simply create a new Freestyle Project “Boozang UI test”.
jenkins-1-create-project
Start by setting Project Name (Boozang-ui-testing) and make sure you link the Jenkins to your local copy of the test code. In our case we use GitHub so we simply put: GitHub project -> https://github.com/ljunggren/boozang-jenkins

jenkins-2-name-and-parameter

Also, it’s recommended to check “This project is parameterized”. This way we can easily set the test url when we trigger the build, and also send the test url as parameter from an upstream build pipeline, utilizing the same job for many different pipelines.

jenkins-3-source-code-mgmt

Next step is to set up the build step. The build step we want to use is “Execute shell” and it looks as follows. The might be more elegant ways to handle npm dependencies, but it does the job. As you can see we run the run-headless-chromium.js script using the parameter $bz_test_url coming from the upstream job.

jenkins-new

Here we use a simple grep to extract the report content being output in the console log. We save the extracted report into reports/result.html In order to make sure a failed Boozang test tool run causes the Jenkins build to fail we again use grep to find any failed runs in the report. It this case we look for a specific string that signifies and error and if we find a match we make sure we generate exit code 1 which signals to Jenkins the build job should be flagged as failed. The console code can be found here.

We also want to save the report so it’s accessible from Jenkins. The way we did that was using the HTML Publisher Plugin setup the following way.

jenkins-5-post-build-reports

After this has been saved, we can easily trigger this job from an upstream pipeline. The report will show up in the Jenkins GUI as a link on the Project Itself.

jenkins-6-end-result

Now every time you push code in an existing pipeline, you can easily trigger user interaction tests in your pipeline by calling

stage ('Run UI tests') {
build job: 'Boozang-ui-test', parameters: [[$class: 'StringParameterValue', name: 'bz_test_url', value: 'http://myserver:myport/jenkins.html
#57965bf168923d9b04c299d9/0.0.001/m7/t1/run']]
}

Happy coding!

Write a Comment

Write a Reply or Comment

Your email address will not be published. Required fields are marked *


Create Your Account Now!

For FREE. No credit card required.

Sign Up