Console cucumber and capybara with Selenium and Hudson
Nowadays, software developers can't live without their favorite test frameworks. But what developers don't want is to ensure that these tests run continuously. Also, the development teams do not want to spend time bringing the test results to everyone.
There are more and more useful applications, libraries and plug-ins, which partially alleviate the headache that arises during attempts to make tests useful for the whole team. Examples of excellent tools that we have at our disposal include Hudson for continuous integration, Cucumber for integration tests and Selenium for automated testing of web applications in a real browser. But the organization of the joint work of all this requires more and more settings and configurations on the assembly server.
Our goal is to document the steps required to overcome the obstacles encountered to launching the complete Cucumber test suite with scripts on Selenium on the Hudson assembly server.
We will use the following ingredients in this topic:
')
We will not dive into the details of creating a Rails application, installing gems, and developing Cucumber scripts. They have their own beautiful manuals.
Let's start by installing a couple of packages that allow us to run tests in a browser without graphics mode.
“On the X Window System, Xvfb or virtual X framebuffer is an X11 server that performs all the operations in memory without showing anything on the screen” - http://en.wikipedia.org/wiki/Xvfb
After installing Xvfb, we can go ahead and install a web browser.
Before we continue, we need to configure the browser profile so that it doesn’t scream about closing tabs or recovering from a crash. If this is not done, the test suite will break down or work forever.
Now we will enter two lines in the user.js file:
Before we start running our tests, we 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 a virtual framebuffer and open the example.com homepage in this browser. Next is to make a "screenshot" so that we can see what is happening inside our virtual framebuffer.
And see our screenshot with:
(And if you set up a remote machine, then you can pick up the xwdout file for yourself and look at yourself - comment of the translator)
See the example.org homepage? So Xvfb and iceweasel were successfully installed and we are ready to conduct several tests.
Before we integrate this setup into our continuous integration environment, we run tests to see if cucumber works with our new configuration. We can do this with the following command, keeping in mind that it is necessary to explicitly tell cucumber to use the virtual framebuffer display:
If everything went well, then we will see that all the scenarios ended successfully. If not all scenarios are successful, check first whether everything is fine in a situation with a normal graphics mode.
Now we have come to try to fly with all this garbage. We need to add a new build step to the task, which should launch our background cucumber. But before adding the assembly step, we will create a start script for our virtual framebuffer. You can use this script to start the buffer before running the scripts and stop the buffer after the scripts have completed. You can save this script in /etc/init.d/. Make sure the permissions are set so that the user that Hudson is running from can execute it.
The final step is to add an “Execute shell” assembly step to the Hudson task. You can use the following set of commands to start your cucumber.
After adding this build step, save our task and let Hudson assemble it. If everything goes well, cucumber scripts will now work as part of our continuous integration process. You can view the “Console output” page of an assembly in Hudson for the reasons for unsuccessful assemblies.
Conclusion
If you have reached this place in this topic, then 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 will not suit 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: Transferred to the "Testing", if the interest of the habrasoobschestva appears, I will write how everything is done with us.
There are more and more useful applications, libraries and plug-ins, which partially alleviate the headache that arises during attempts to make tests useful for the whole team. Examples of excellent tools that we have at our disposal include Hudson for continuous integration, Cucumber for integration tests and Selenium for automated testing of web applications in a real browser. But the organization of the joint work of all this requires more and more settings and configurations on the assembly server.
Our goal is to document the steps required to overcome the obstacles encountered to launching the complete Cucumber test suite with scripts on Selenium on the Hudson assembly server.
Ingredients
We will use the following ingredients in this topic:
- 1 install 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 (Not necessarily such a version, since 3.0.0 everything is ok - approx. Translator)
- 1 heme 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.
Installing Required Packages
Let's start by installing a couple of packages that allow us to run tests in a browser without graphics mode.
Virtual framebuffer with Xvfb
“On the X Window System, Xvfb or virtual X framebuffer is an X11 server that performs all the operations in memory without showing anything on the screen” - http://en.wikipedia.org/wiki/Xvfb
$ apt-get install xvfbWeb browser
After installing Xvfb, we can go ahead and install a web browser.
$ apt-get install iceweaselBefore we continue, we need to configure the browser profile so that it doesn’t scream about closing tabs or recovering from a crash. If this is not done, the test suite will break down or work forever.
$ cd ~/.mozilla/firefox/xxxxxxxx.default/
$ vim user.js
Now we will enter two lines in the user.js file:
user_pref("browser.sessionstore.enabled", false);
user_pref("browser.sessionstore.resume_from_crash", false);
Display check
Before we start running our tests, we verify that all packages are installed correctly. To do this, start the virtual framebuffer (Xvfb session) on display 99 with screen 0:
$ Xvfb :99 -ac -screen 0 1024x768x16
In another terminal window write:
$ DISPLAY=:99.0 iceweasel example.org
This will launch our web browser in a virtual framebuffer and open the example.com homepage in this browser. Next is to make a "screenshot" so that we can see what is happening inside our virtual framebuffer.
$ xwd -root -display :99.0 -out xwdout
And see our screenshot with:
$ xwud -in xwdout
(And if you set up a remote machine, then you can pick up the xwdout file for yourself and look at yourself - comment of the translator)
See the example.org homepage? So Xvfb and iceweasel were successfully installed and we are ready to conduct several tests.
Run cucumber
Before we integrate this setup into our continuous integration environment, we run tests to see if cucumber works with our new configuration. We can do this with the following command, keeping in mind that it is necessary to explicitly tell cucumber to use the virtual framebuffer display:
$ DISPLAY=:99.0 rake cucumber
If everything went well, then we will see that all the scenarios ended successfully. If not all scenarios are successful, check first whether everything is fine in a situation with a normal graphics mode.
Hudson configuration
Now we have come to try to fly with all this garbage. We need to add a new build step to the task, which should launch our background cucumber. But before adding the assembly step, we will create a start script for our virtual framebuffer. You can use this script to start the buffer before running the scripts and stop the buffer after the scripts have completed. You can save this script in /etc/init.d/. Make sure the permissions are set so that the user that Hudson is running from can execute it.
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
The final step is to add an “Execute shell” assembly step to the Hudson task. You can use the following set of commands to start your cucumber.
#!/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, save our task and let Hudson assemble it. If everything goes well, cucumber scripts will now work as part of our continuous integration process. You can view the “Console output” page of an assembly in Hudson for the reasons for unsuccessful assemblies.
Conclusion
If you have reached this place in this topic, then 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 will not suit 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: Transferred to the "Testing", if the interest of the habrasoobschestva appears, I will write how everything is done with us.
Source: https://habr.com/ru/post/123565/
All Articles