I recently installed as the Hudson continuous integration server for my project at work. I would prefer not to install Hudson or Cruise Control Continuum for two reasons: Hudson highly recommended to me by my former employee (thanks Mike!), And when I chose between them, the site of Hudson was much clearer, and it was much easier to navigate. I’m not here to write about installing Hudson, because it is very simple and done in just a minute, as well as in the interface there are lots of tips for installation. In this series of posts I’m going to tell you how to configure Hudson to testing with Selenium on headless Linux server. I also want to note that I would love to confess about Linux just a high level, so as, at a time when I decided on this adventure, knowledge and experience with Linux I have been pretty basic, and I had the most to reduce all the information received from various sources. But it’s still not for complete beginners in Linux. You need to know at least how to install packages, and navigate the file system from the command line before reading it.
Note to the uninitiated: Selenium – free software for testing Web-based applications at the UI level. It uses JavaScript to interact with Web pages, so it is possible to prescribe a series of user actions and ensure that the application in the browser works as you expect. However, this series of posts will not tell anything directly about how to install Selenium, just as it does not tell about the installation and Hudson.
So, let’s move on to part one. Assume that your package is already testing a few tests with Selenium and you want them to work with the add-Hudson on your headless server. Headless means that the high possibility that you are not running X server, but you can not use Firefox or the browser of your choice without the X server, simply put, this means that you can not use your web application. How about that instead of installing a fully functional X server only for a few UI tests using a virtual display? With this you will help a great tool, called Xvfb. Xvfb runs a basic virtual display in memory, so applications that need the functionality of graphical tools that can run on machines without the X server.
Step one is required to ensure that the application Xvfb installed. Please note that this means that you must also be installed X server. Yes, Xvfb virtual display creates an easy, but he still uses to this X server. If Xvfb is installed, you must appear somewhere in the executable binary code named Xvfb: perhaps in / usr / bin. I think he will be there. Next, you need to run it:
1 / Usr / bin / Xvfb: 5-ac-screen 0 1024x768x8
How it is divided:
1 / Usr / bin / Xvfb
Well, that’s the code that launches Xvfb. There.
Now Xvfb should work seamlessly display you require. The values ??that you set for "display" and "display number" are important, and unite in the form of ":." In order to specify exactly what combination of Linux display / screen is used for display. In the example above you would use the ": 5.0" to indicate Linux is configured to use a single screen. I should also add that, apparently, no matter which user starts the Xvfb, so that you can create a startup script in / etc / init.d and give him the opportunity to work as an administrator, if you do want. Can test the Xvfb, launching a graphical application and make a screenshot.
Opportunity to make a screenshot of the virtual display itself is quite important. To make and view a screenshot you’re using two different programs: xwd and xwud. First make a screenshot, and the second will show it. They must be installed on your X server (I think).
First, run the xclock on a system that is running Xvfb with xclock-display: 5.0 so that it will work on the virtual display. Further, as the system with Xfvb, make a screenshot
1 xwd-root-display: 5.0-out xwdout
Sequence:
Once you make a screenshot, you need to open the output file on the system is running a real X server, so you can see the image. For this fit ftp or sftp, scp, or good old Sneakernet. In the end, look at the screenshot, you made: xwud-in xwdout. Thus, we show an image stored in a file called xwdout. It should open in a window where you see a small xclock, showing the time when he was made a screenshot. Click on any location in the window to close it.
Now we need to get it to work with Selenium tests in your add-ins, Hudson. The first, my work was done in Selenium RC, which need to run separate Selenium Server, which is responsible for starting the browser and receives commands from your test scripts to be run in browsers. I’m not very familiar with other types of Selenium, so I can not say how similar is their installation.
First, Selenium should know what browser it is necessary to start and / or how to start or what display to use. If you’re already using Selenium RC, you know that you need to pass the name of the browser in Selenium, to specify which browser to use. In any case, if you normally work in Windows, and Selenium can not find a Firefox or IE on your Linux, you may need to perform some certain configurations. Usually the command to start the browser Firefox – it "* firefox". In Selenium is a default folder in which the Selenium looks for a file starting Firefox. If it can not find it, you can specify it manually, eg * firefox / usr / bin / firefox-bin. This tells Selenium that you need to run Firefox and have to use the path specified. You must specify the path to firefox-bin, and not just the script firefox. Selenium check the availability of a script or executable binary code and if that program will generate an exceptional case. There is also the ability to simply pass the path and arguments to Selenium, leaving a pointer "* firefox", but as they say in the documents, "If you provide your own set by the user browser configuration is correct will depend on you. At a minimum you will need to configure your web browser to use the Selenium Server as a proxy, and disable all browser settings. "
Very easy to do so using Selenium virtual display. Setting an environment variable called "DISPLAY" in the Linux says it runs any graphics application to run on the specified display, therefore, deal only to properly specify this variable for server processes Selenium. Remember that this server is responsible for launching the browser, so it is here should be available variable DISPLAY. If you run a server with a shell can be done simply export DISPLAY =: 5.0 before running the server. Naturally, you will need to make sure that the numbers coincide with the display and the screen, which you configured in Xvfb. (See the first post of this series for more information.) If you run a server with Ant, just add an element of compound to target <jar>, which is as follows:
1 <env key="DISPLAY" value=":5.0" />
In any case, remember that if you add it to your build script, so that you bind all Linux users for this display. It’s probably not too good.
In the end, make sure that Hudson managed vsemb tasks correctly. This may be the smallest part, so as Hudson can trigger shell scripts, goals Ant, the problem Maven, and many other things. Make sure that Xvfb is running or that Hudson starts it. Make sure your application server / web container is running or that Hudson starts it. Make sure that any other thing on which your application depends on are available, such as a database. Make sure that the Hudson builds your web application and use them properly. Make sure that the Selenium server is running or that Hudson starts it. Then, get Hudson to initiate a goal, task, or anything that runs your package for testing Selenium. So as Selenium tests are written as regular tests with JUnit or TestNG, etc., it really does not matter. The only tricky moment in all this is that you will need to make sure that the tests will not begin until your application is fully launched. It’s entirely possible when testing begins even before the URL for your application will be available on your web server.
That’s it! When you run the client Selenium, he will report to the command "start" the server, which will launch a browser on a virtual display. Then tests will be carried out exactly as usual, by issuing a command server Selenium, and then the browser, which makes HTTP requests to your Web server is running an application that runs Hudson. You can use xwd and xwud, as indicated in the second post, to make and view screenshots of browsers during the tests. Great idea that I introduced into our environment, is to install a listener on freymforki for testing (I used ITestListener of TestNG), which will make a screenshot every time the test fails. This will give you an extremely useful feedback removal, which you can use the error checking.