Postings of February, 2012

Handle authentication during WebDriver testing

Saturday, 25. February 2012 20:03

Sometimes authentication is necessary before a test case can be executed. While HtmlUnit based tests can easily enter and confirm authentication requests, most browser based tests, cannot workaround the dialog. This is a browser security measure to prevent automated data capture and/or data entering. WebDriver for Firefox delivers a solution for that problem, but IE and Chrome rely on a manual interaction with the browser before the test automation can run.

The following steps describe a solution for the authentication problem and how to run a script test case as WebDriver based test. The key to this solution is the usage of Sikuli, an image based testing tool that directly interacts with the screen to find the right elements by using the screen.

Or in other words, the test automation controls the browser, not the operating system, while Sikuli controls the display of the operating system and uses the keyboard and mouse to control any program.

  • Download Sikuli tool for your platform (http://sikuli.org)
  • Extract the zip file
  • Add the path to Sikuli lib directory to your environment settings
  • Add sikuli-script.jar to your project
  • Implement a Java class as shown below
  • Take the necessary screenshots of the elements to use
import org.junit.Test;
import org.openqa.selenium.ie.InternetExplorerDriver;
import com.xceptance.xlt.api.engine.scripting.AbstractWebDriverScriptTestCase;
import com.xceptance.xlt.engine.scripting.XlteniumScriptInterpreter;
import org.sikuli.script.*;

public class TfoobarIE extends AbstractWebDriverScriptTestCase
{
    /**
     * Constructor starts internet explorer 
     */
    public TfoobarIE()
    {
        super(new InternetExplorerDriver(), "http://xlt.xceptance.com");
    }
    
    /**
     * Main test method solves authentication problem and executes xlt script developer script
     */
    @Test
    public void test() throws Throwable
    {   
    	// create Sikuli screen object
    	Screen s = new Screen();

    	// open page with xlt
    	open("/demo/");

    	// wait 5 seconds for the image with the username input field 
    	s.wait("./img/username_input_field.jpg",5);

    	// type username "demo" into the input field
    	s.type("demo");    

    	// type password into the password field
    	s.type("./img/password_input_field.jpg","demoomed!");

    	// click ok button
    	s.click("./img/ok_button.jpg");
    	
    	// execute xlt script developer script
    	XlteniumScriptInterpreter interpreter = new XlteniumScriptInterpreter(getWebDriver());
    	interpreter.executeScript("Tfoobar");   	
    }
}

Do not forget to make the appropriate screenshots of the buttons and input fields (see code) and of course, adjust the path and login data. Have fun and watch the magic happening. For more information how Sikuli works, please visit sikuli.org.

Category: Automation, Java, Testing, XLT | Comments (2) | Author:

Discontinued support of JRuby

Thursday, 23. February 2012 9:56

The upcoming Xceptance LoadTest 4.2 will discontinue the direct support of JRuby as a programming language for writing test cases. This will not change the way Java and JRuby interact and therefore you can still use all Java components and integrate them into your JRuby-based test suite. You can also still write test cases in Ruby and use XLT-APIs.

You can read about this feature, in case you are not sure whether or not you will be affected by this change: XLT 3.3.0 JRuby support release note.

Version 4.2 of Xceptance LoadTest will not continue the JRuby package anymore (jruby.jar). The test execution scripts for JRuby-based tests and all demo test cases will be removed as well.

If you have any questions regarding this change, please do not hesitate to contact our support team directly.

Category: Software, XLT | Comments (2) | Author:

XLT 4.1.8 Update Release

Saturday, 18. February 2012 0:15

XLT 4.1.8 has been released. It contains a couple of improvements and bug fixes. You can get the latest version here: https://lab.xceptance.de/releases/xlt/4.1.8/.

These are the two most important changes.

Optimized scanning CSS rules

XLT simulates the download behavior of a browser as close as possible. With com.xceptance.xlt.css.download.images set to onDemand, XLT carefully considers the download of image resources referred to in CSS files. It checks all CSS rules if they apply to all elements in the DOM tree and, if so, extracts the resource information for later download. This process was previously very expensive and ran for up to several seconds when a page was complex and a lot of CSS rules had to be matched. This has been optimized heavily.

Configurable retry behavior for keep-alive connections

If persistent connections (keep-alive) are enabled, test cases might failed sporadically with an exception such as:
java.lang.RuntimeException: org.apache.http.NoHttpResponseException: The target server failed to respond

This exception occurs only when the request was sent while the connection was about to be closed on the server side at the same time.

The underlying HttpClient retries requests if the connection was closed by the server. However, by default it retries only idempotent operations such as GET and HEAD, but not POST and PUT. In order to avoid these connection errors, the user can now configure whether non-idempotent operations are to be retried as well. Common browsers seem to use the same behavior and most certainly assume that the server did not start to process the request when it closes the connection immediately without responding with a proper HTTP status code.

A new boolean property com.xceptance.xlt.http.retry.nonIdempotentRequests in config/default.properties controls whether or not operations such as PUT and POST are retried in case of certain networking problems. Note that idempotent operations are always retried.

Category: Performance, Software, Testing, XLT | Comments (0) | Author: