Selenium onLoad() handling

At APT, we’ve recently completed a transition to using Selenium’s Java RC¹ for our regression testing framework. One of the excellent things about Selenium RC is the ability to add functionality with relative ease.

In this entry, I want to briefly cover how we get around the onLoad() event caveat of Selenium. Since Selenium works by Javascript injection, it is unable to catch onLoad() events, which can prove to be troublesome when dialog boxes are hit onLoad(). Our code base is relatively large for such a small company and in testing we are really pushing the limits of Selenium. Our goal is to have all of our front-end testing done through Selenium, which means that it needs to elegantly handle Javascript errors and onLoad confirmations/alerts.

When executing an action such as click(), Selenium can hang if a Javascript error is hit. In order to handle this, we now spawn a separate thread to handle any action that might alter the state of the page. The main thread is then able to poll and check if the action thread has hung and if it has we call an AutoIt script² which closes the dialog box and logs an error to our database. This is especially powerful because it lets our tests continue to run with virtually no human interaction.

By leveraging anonymous classes in Java, any Selenium function can quickly be overloaded and run in a custom multithreaded execution thread, as well as make any encountered errors available for the main thread to handle.

This is just an example of how we are automating Selenium, which is crucial in order for it to work with our distributed framework. In my next blog entry I would like to cover how we are accomplishing quick distributed compilation.

- Dan Hackner

1 – http://seleniumhq.org/projects/remote-control/

2 – a Window’s GUI level scripting language. http://www.autoitscript.com/autoit3/

Starting Selenium Server in Java

For some of our automated tests we are switching to use the open-source project Selenium-RC. You can read more about it at its web site: http://selenium-rc.openqa.org/, but essentially it runs a java server which can control an internet browser, and then your testing code sends commands to this server. One key part of this setup is that you need the server running while your testing code is executing. For automated testing machines it would be no big deal to make the Selenium server a service; however developers probably don’t want it running all the time—in fact they do not want to think about it!

Thus our solution was to have our testing code launch the server. I’ve seen a number of posts on various forums asking how to start the selenium server form Java, but none of them had concrete answers. Thus I will reproduce our implementation for you to use and modify as you please:

Process p = null;

try {

    String[] cmd = {"java","-jar","C:\\<path to selenium>\\server\\selenium-server.jar" };

    p = Runtime.getRuntime().exec(cmd);

} catch (IOException e) {

    System.out.println("IOException caught: "+e.getMessage());

    e.printStackTrace();

}


System.out.println("Waiting for server...");

int sec = 0;

int timeout = 20;

boolean serverReady = false;

try {

    BufferedReader input = new BufferedReader(new InputStreamReader(p.getInputStream()));

    while (sec < timeout && !serverReady) {

        while (input.ready()) {

            String line = input.readLine();

            System.out.println("From selenium: "+line);

            if (line.contains("Started HttpContext[/,/]")) {

                serverReady = true;

            }

    }

        Thread.sleep(1000);

         ++sec;

    }

    input.close();

} catch (Exception e) {

    System.out.println("Exception caught: "+e.getMessage());

}



if (!serverReady) {

    throw new RuntimeException("Selenium server not ready");

}



System.out.println("Done waiting");

Some notes on the above code:

I left in some handy print statements; however these are of course completely optional.

For non-automated testing machines, be sure to have your outer most try-catch block of your testing code kill the server or it may be left running even when the testing code finishes.

For code on automated testing machines, you may want to check to see if the server is running and start it only if it is not. This way you don’t waste time waiting for the server to be ready if another test already brought it up.