Integrating Selenium into Jenkins

6. 3. 2015 Ondřej Kratochvíl

First of all, what exactly is Selenium capable of? Well, it automatizes all the clicking you do after you have made some changes and check if you didn’t break anything. It can do simple things, like click on a specific element, wait for page to load, wait for an element to be present on the page (very useful for ajax requests), but also some more advanced commands, e. g. execute JavaScript code snippet, simulate mouse movement, work with cookies, store variables, drag and drop and much more. On top of that, there is no need to write a single line of code in order to implement such tests - all of this could be done via graphical interface of Selenium IDE Firefox plugin that generates a simple .html file with a table of individual commands and their parameters, which we will be using later.

All of this is very nice, so we decided to hook these tests to Jenkins as a post-build action. In order to function properly, we need a few extra plugins for Jenkins:

The Selenium plugin is responsible for launching the Selenium RC server and generating result file. Xvfb (Virtual frame buffer) plugin lets us launch a virtual display on our server in which Firefox will be launched. And lastly, we use the Email extension plugin to send our developers email with the result file after every successful build, as the email Jenkins is sending by default does not let us to attach a file. The desired Jenkins functionality would be as follows:

  • Build the project
  • Deploy the application on the daily server
  • Launch a virtual display
  • Launch Selenium server
  • Run Selenium tests
  • Shut down virtual display and Selenium server
  • Send an email report of the test results

In order to make this work properly, we need to download the Selenium server jar, which has to be located on our server. And of course, Firefox (or any other Selenium supported browser) has to be installed on the machine.

When all of the above is set up, we can start configuring Jenkins. Firstly, we need to make some global changes. Open up the web interface and go to Manage Jenkins -> Configure System. Find the section “Global properties” and add an environment variable named “DISPLAY” with value“:99” - this lets us to launch the virtual frame buffer on display 99, that will most likely not be used. Then in the section “Selenium Remote Control”, enter the path of the Selenium server .jar file and that is all concerning global configuration. Next, go to your project in Jenkins and click Configure. In the “Build Environment”, check the “Start Xvfb before the build, and shut it down after”checkbox, so that Xvfb would not run all the time as it is only needed for Firefox to run in it during the tests. Next up, click “Advanced options” and set “Xvfb specific display name” to 99, as we set in the global settings. Now comes the most important (yet very easy) part - configuring the Selenium server itself. Scroll down to the “SeleniumHQ htmlSuite Run”. The browser we are using is Firefox, but you can use any browser that is supported by Selenium. However, the browser name must be in the form


e. g. *firefox, *googlechrome, *iexplore and so on. StartURL will be the url where you want to run your tests, in our case, the daily server. SuiteFile is the path to the .html file that contains a table with the links to separate tests. This is the file that was created by Selenium IDE and the path to it can be either absolute, relative to Jenkins workspace, or a valid URL. ResultFile is a path where the result .html file will be saved. I highly recommend to save it to the build folder and delete older builds (e. g. keep only 10 last builds - this can be configured in the “Discard old builds” section), so that old result files will not remain on the disk forever. Lastly, we have to set up email notifications. Go to section “Post-build Actions/Editable Email Notification” and fill in Project Recipient List (careful, individual emails have to be separated by commas, whereas in the default Jenkins emails they are separated by spaces). Next up, select “HTML”Content Type and add the .html result file into Default Content text area. The file should be in the form


Then, click on advanced settings and set trigger to “Success” and send to “Recipient List”.

And that’s it! Now, each time you commit changes to your version control system, Jenkins will not only build the project and run unit tests, but also run integration tests in a real browser, following the steps a real user would make. A few last hints from me - be sure to append the names of your suite files and tests with .html, as Selenium will be unable to launch them if they don’t end with *.html. And I would also recommend using Jenkins variables when specifying source and target paths - for instance ${BUILD_NUMBER}, ${BUILD_ID} and more, for example when you want to keep only X last builds and discard the rest.

I hope this tutorial was useful and wish you successful testing :)