Console cucumber and capybara with Selenium and Hudson

Original author: Ludo van den Boom
  • Transfer
Nowadays, software developers cannot live without their favorite test frameworks. But what developers do not want is to ensure that these tests run continuously. Also, the development team does not want to waste time on bringing the test results to everyone.

There are more and more useful applications, libraries and plugins that partially alleviate the headache that arises from trying to make tests useful to the whole team. Examples of great tools we have at hand are Hudson for continuous integration, Cucumber for integration tests, and Seleniumfor automated testing of web applications in a real browser. But organizing the collaboration of all this requires more and more settings and configurations on the build server.

Our goal is to document the steps required to overcome the obstacles encountered in running the full Cucumber test suite with scripts on Selenium on the Hudson build server.

The ingredients


We will use the following ingredients in this topic:
  • 1 installation of Debian 5.0.4 'Lenny'
  • 1 xvfb installation
  • 1 Web browser (in our case, iceweasel , Firefox after Debian rebranding
  • 1 application for Ruby on Rails 2.3.7 (This version is not necessary, since 3.0.0 everything is OK - approx. Translator)
  • 1 gem Capybara 0.3.8
  • cucumber (0.7.3) to taste


We will not dive into the details of creating a Rails application, installing gems, and developing Cucumber scripts. They have their own beautiful manuals.

Install the required packages



Let's start by installing a couple of packages that will allow us to run tests in a browser without graphical mode.

Virtual framebuffer using Xvfb


“In the X Window System, Xvfb, or virtual X, the framebuffer is an X11 server that performs all operations in memory without showing anything on the screen” - http://en.wikipedia.org/wiki/Xvfb

$ apt-get install xvfb

Web browser


After installing Xvfb, we can go ahead and install a web browser.

$ apt-get install iceweasel

Before we continue, we need to configure the browser profile so that it does not ache about closing tabs or recovering from a crash. If this is not done, the test suite will break or will work forever. Now we enter two lines in the user.js file:

$ cd ~/.mozilla/firefox/xxxxxxxx.default/
$ vim user.js




user_pref("browser.sessionstore.enabled", false);
user_pref("browser.sessionstore.resume_from_crash", false);


Display check


Before we start running our tests, we will verify that all packages are installed correctly. To do this, start the virtual framebuffer (Xvfb session) on display 99 with screen 0: In another terminal window, write: This will launch our web browser in the virtual framebuffer and open the main page example.com in this browser. Then we have to take a “screenshot” so that we can see what is happening inside our virtual framebuffer. And look at our screenshot with: (And if you are setting up a remote machine, you can pick up the xwdout file for yourself and see it with yourselves - approx. Translator) See the main page of example.org? So Xvfb and iceweasel were successfully installed and we are ready to conduct several tests.

$ Xvfb :99 -ac -screen 0 1024x768x16




$ DISPLAY=:99.0 iceweasel example.org




$ xwd -root -display :99.0 -out xwdout



$ xwud -in xwdout




image

Running cucumber



Before we integrate this setup into our continuous integration environment, we will run a test run to see if cucumber works with our new configuration. We can do this with the following command, keeping in mind that you must explicitly tell cucumber to use the virtual framebuffer display: If everything went well, then we will see that all the scripts completed successfully. If not all scenarios are successful, first check to see if everything is fine in a situation with normal graphics mode.

$ DISPLAY=:99.0 rake cucumber




Hudson configuration



Now we have come to the point of trying to take off with all this garbage. We need to add a new build step to the task, which should start our background cucumber. But before adding the assembly step, we will create a start script for our virtual framebuffer. This script can be used to start the buffer before running the scripts and stop the buffer after the scripts finish. You can save this script in /etc/init.d/. Make sure that the permissions are set in such a way that the user from whom Hudson is running can execute it. The final step is to add the “Execute shell” type assembly step to the Hudson task. You can use the following set of commands to start your cucumber.

XVFB=/usr/bin/Xvfb
XVFBARGS="$DISPLAY -ac -screen 0 1024x768x16"
PIDFILE=/var/hudson/xvfb_${DISPLAY:1}.pid
case "$1" in
start)
echo -n "Starting virtual X frame buffer: Xvfb"
/sbin/start-stop-daemon --start --quiet --pidfile $PIDFILE --make-pidfile --background --exec $XVFB -- $XVFBARGS
echo "."
;;
stop)
echo -n "Stopping virtual X frame buffer: Xvfb"
/sbin/start-stop-daemon --stop --quiet --pidfile $PIDFILE
echo "."
;;
restart)
$0 stop
$0 start
;;
*)
echo "Usage: /etc/init.d/xvfb {start|stop|restart}"
exit 1
esac
exit 0




#!/bin/bash
export DISPLAY=:99
/etc/init.d/xvfb start
rake cucumber
RESULT=$?
/etc/init.d/xvfb stop
exit $RESULT


After adding this build step, we will save our task and let Hudson build it. If everything goes well, cucumber scripts will now work as part of our continuous integration process. You can look at the Console output page of the assembly in Hudson to find the reasons for the failed assemblies.

Conclusion



If you have reached this place in this topic, now you have a working background installation. The advantage of this installation is that it is quite lightweight and easy to configure. But this setting is not suitable for you if you need to test with several different browsers. For this setup, you will have to look towards the virtual machines and Hudson subordinate agents.

UPD: Moved to "Testing", if the interest of the habrasociety manifests itself, I will write how it is done.

Also popular now: