Making today worse so tomorrow seems better.

Bring Selenium to the Integration Party


Running Selenium on a headless box. Not particularly complex, but amazingly useful for integration testing.

Do you wish you could leverage the power of Selenium? Do you long for it’s “automated web application UI tests”, but are boned by some headless horseman of a server? I have felt your pain. Tons of UI tests, but unable run them on the integration server. Ah, but there is a light at the end of the tunnel (that isn’t convincing the hosting company to attach a monitor)!

Here is the gist of it:

   nohup Xvfb :4 -screen 0 1024x768x24 2>&1 > xvfb.log &
   sleep 3 # give Xvfb a few seconds to sort itself out
   DISPLAY=4 nohup java -jar selenium-server.jar 2>&1 > selenium.log &

Basically, Xvfb creates a virtual X session, without the need for those kludgey monitors and keyboards. The Selenium Remote Control server is started up with the newly created Xvfb display, that is the DISPLAY=4 part. That is that, the Selenium server is now running on the default 4444 port using Xvfb.

Why do I care? Previously I use to be stuck running Selenium tests only on my development machine, now our automated build servers like CCrb or Hudson (we actually use both) can execute all the tests, including selenium.

For team Debian, Xvfb can be installed with apt:
   apt-get install xvfb
The Redhat club can get Xvfb with yum:
   yum install xorg-x11-server-Xvfb

And the Selenium Remote Control selenium-server.jar from OpenQA

Inspired by Jordan Sissel’s post