Using VNC as the display manager to run Selenium tests
Most of local development happens in some virtual environment of some sort, either virtual machines or containers. Actually, this blog post comes directly from the fact that I was porting some older script we used internally to bring Selenium support to our newer ce-vm development stack.
These virtual environments normally don’t have a display, which means that running Selenium tests is usually done using a “headless” display manager. Typically, XVFB is the standard one.
It works well and is very useful to automate tests with CI tools, run a series of suites, etc. However, it lacks any visual feedback: you get the test results, possibly screenshots depending on your stack/tools. But you cannot see the browser “performing live”.
An alternative is to use a VNC server as the display manager instead of a headless one. That will let you connect to your VM/container using any VNC-compatible client from your “host” machine and watch the browser act.
Why would you do that in the first place? Well, seeing what the browser is actually doing is very useful to catch more quickly why certain tests are failing or are hitting timeouts, especially with JS/AJAX elements. Plus it is mesmerising to watch!
I will skip all the automated steps and creation of a proper “start” script (you can refer to the ansible role for more details) and focus only on the manual parts.
All the steps below are performed as a non-privileged user — in our case the “vagrant” user. Admittedly, it’s not a production box, but you still probably don’t want to run a VNC server as “root”, so you should create a user for this if you don’t have one already.
Assuming you downloaded the Selenium Standalone Server to /opt/selenium-server-standalone.jar and fullfilled all java and browser requirements, a typical “start” — on the Debian distribution of Linux in this case — would be to:
- install Xvfb:
sudo apt-get install xvfb2. start it with a display number:
/usr/bin/Xvfb -ac :99 &3. start Selenium/Java on the same display
export DISPLAY=:99
/usr/bin/java -jar /opt/selenium-server-standalone.jar &Looks familiar ?
For VNC, we are going to take a slightly different approach, and start Selenium/Java from within the X session directly.
We are using TightVNC server here, because it is lightweight and compatible with nearly all clients, but others would work in a similar way.
If you are trying this live, make sure neither Java/Selenium nor Xvfb are already running to avoid port conflicts.
Also make sure you host will be able to access the port the VNC server will be listening on (5999 in this example) in your VM/container. The exact mechanism will of course vary depending on your host OS, virtualisation/containerisation method and networking setup, but it is usually done by forwarding/exposing it.
So our steps now — still on Debian — would be:
- install TightVNC (xterm is optional but convenient):
sudo apt-get install tightvncserver xterm2. make a “~/.vnc” folder and a “~/.vnc/xstartup” file containing:
#!/bin/sh
[ -x /etc/vnc/xstartup ] && exec /etc/vnc/xstartup
[ -r $HOME/.Xresources ] && xrdb $HOME/.Xresources
xsetroot -solid grey
export DISPLAY=:99
java -jar /opt/selenium-server-standalone.jar &
x-terminal-emulator -ls -title “$VNCDESKTOP Desktop” &3. make sure it is executable:
chmod +x ~/.vnc/xstartup4. start the VNC server, which will also take care of starting Selenium/Java:
/usr/bin/tightvncserver :99The first time, you will be asked to create a password, that you will use to connect from your host machine.
You should now be able to use any VNC client (even the pesky built-in one from Mac OSX) to:
- reach vnc://ip.of.the.guest:5999 (if you’re using ce-vm this will be vnc://app-vm.codeenigma.com:5999)
- be prompted for the password you choose above
- be presented with an ugly (!) minimalist grey background and a terminal window
You are done. Run your tests as usual, and watch the browser open itself within the remote desktop and run your tests right before your eyes.
Exciting, no?
