watermark
An example of an old VNC

Using VNC as the display manager to run Selenium tests - A How-To Guide

 

 

We're going to talk about 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:

  1. install Xvfb:

2. start it with a display number:

3. start Selenium/Java on the same display

 

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, ensure you host can access the port the VNC server will be listening on (5999 in this example) in your VM/container. The exact mechanism will 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:

  1. install TightVNC (xterm is optional but convenient):

2. make a "~/.vnc" folder and a "~/.vnc/xstartup" file containing:

3. make sure it is executable:

4. start the VNC server, which will also take care of starting Selenium/Java:

The first time, you'll be asked to create a password. This is for 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

That's it! Run your tests as usual. Then watch the browser open itself within the remote desktop and run your tests right before your eyes.

And that's how Using VNC as the display manager to run Selenium tests is done!

 

Written by

Pascal Morin

Director