CM, Jenkins and Selenium

(Jerker Montelius)

1 Intro

One of the "holy grails" of CM is and always has been to be able to test user interfaces. This has not been easy thou. To be able to "click" on buttons in an application has no easy or general solution. However, with the rise of HTML application as the standard interface makes our job a little bit easier as it actually standard parsable. Now we just have to select the right tools.

2 The Tools

2.1 Git

Git is the the version control system I choose to hold the Selenium test and test suite files.

2.2 Trac

Trac has a excellent web interface to git so you easily can browse change sets and check-ins.

2.3 Jenkins

Jenkins is a a (CI) continues integration engine that integrates easily with the other components.

2.4 Cloudstack

Cloudstack is a cloud operating system which allows you to spin up new machines and networks at will.

2.5 Selenium

Selenium is the magic sauce in this soup. Selenium was built by Google to test their web applications. It consist of mainly two parts. One browser plug-in which allows you to "record" a sequence of HTML actions and store it as a HTML test-file. Multiple test-files can be linked together in a suit file. The second part is a server capable of replaying the pre recorded


3 The set-up

3.1 Install the Firefox plug-in

This is relay simple. Just search for Selenium 2.0 or later in the plugin repository.

3.2 Record the test files

Point your browser at the site you wish to test. Start the recording and use the site in a way that you like. Stop the recording and save the test-file. Repeat as long as you have things to test. Combine the test-files in a test-suite. and add and check in the files in git.

3.3 Selenium server set-up

3.3.1 Create a new machine in Cloudstack

This is pretty standard and I recoment a CentOS machine.

3.3.2 Install software in selenium server

yum -y install Xvfb git java nano

useradd jenkins -p jenkins

cat >/etc/init.d/xvfb <<EOT



# Init file for Xvfb


# chkconfig: 345 98 02

# description: Xvfb start and stop

if [ -z "$1" ]; then

echo "`basename $0` {start|stop}"



case "$1" in


/usr/bin/Xvfb :5.0 -ac -screen 0 1024x768x8 &



killall Xvfb




chmod 755 /etc/init.d/xvfb

/etc/init.d/xvfb start

chkconfig --add xvfb

3.3.3 Set up the Jenkins job

export DISPLAY=:5.0


java -jar ${WORKSPACE}/test/selenium-server-standalone-2.34.0.jar -htmlSuite *firefox ${WORKSPACE}/test/test_suite1.html ${WORKSPACE}/result.html

3.3.4 Parse the selenium result

Add a Post-build action to publish the selenium result.

4 Conclusion

OK Now we have this up and running. What does it lead to process wise?

4.1 Automated test for dummies

We have significant reduced the bar for creating automatic test. A non programmer can now effectively work as a tester and produce automatic test scripts. This was not possible even with the xJunit test approach.

4.2 Automated Build install and test phase

With other approaches we have already automated build and install phase. Automatic tests is the last link in the chain that really allow a lean approach to development.

4.3 Automated acceptance test

With this kind of automatic test you can greatly reduce the time and the required human resources needed for a successful deploy. You can also do deploys on "off-hour's" without the need for a large standby group of testers.