Test Automation Blog

If the application you are testing tends to open new browser windows using the target="_blank" technique, you might have some problems with Selenium.

One of the reasons I find Selenium a great test automation tool for the web  is that it lets you easily run your test scripts on different browsers without too much effort. Most scripts will run smoothly on IE, Firefox and even on more exotic browsers like Safari, Opera and Chrome without needing browser-specific code or having to tweak the test for a particular browser.  One of the few areas where you are likely to face problems is the handling of pop-up windows.  If the application you are testing tends to open new browser windows using the target="_blank" technique, you might have some problems with Selenium. The standard .selectWindow() method provided by Selenium requires either a title of the pop-up window (which is often the same as the title of the main window) or a name or a variable name (which are both missing, when the window is opened using a target="_blank" link).

You will need a workaround to select such windows and unfortunately the workarounds do not always work the same for all browsers. The following code snippets might be useful if you run into the same problem. They are tested on the *chrome and *iehta Selenium modes (with Internet Explorer 7 and Firefox 3).

Here is how you can select the pop-up window which is opened after a target="_blank" link is clicked. This actually combines several hacks and workarounds, but works at the end (at least for me):

        //A hack to select unnamed pop-up windows
        if (browser.equals("*iehta")){
            //Find out if Selenium substituted the blank target...
            if (selenium.isElementPresent(
                       "//a[starts-with(@target,'selenium_blank')]")) {
                // ...and make it notice the new window on IE
                selenium.openWindow("", selenium.getAttribute(
                      "//a[starts-with(@target,'selenium_blank')]@target"));
            }
        }
        String [] winNames = selenium.getAllWindowNames();
        //the last one is the pop-up window we want
        selenium.waitForPopUp(winNames[winNames.length-1], timeout);
        selenium.selectWindow(winNames[winNames.length-1]);

And here is how you can go back to the main window after you finished working with the pop-up:

        String [] winTitles = selenium.getAllWindowTitles();
        selenium.selectWindow(winTitles[0]);

"Testers get indignant when they realize that the quality tools purchased at a serious price are themselves full of bugs. Indeed, test tools are often buggier than comparable (but cheaper) development tools. Plan to test your tools and spend time finding workarounds for bugs."

The quote comes from one of the best books on software quality I have read - Lessons Learned in Software Testingby Cem Kaner, James Bach and Bret Pettichord.  Be sure to read it if you haven't already.
I can not agree more with the authors. I spend a lot of my time in test automation trying to find workarounds for issues with the tool. Some of those issues can be considered 'functional idiosyncrasies', but most are just plain and simple bugs. During my work in the field of software quality I have noticed that users are normally quite tolerant of bugs, unless the bugs block them from doing their jobs. So for me there are two kinds of bugs in the test tools - those you can find a workaround for and those you can not.
If the tool is flexible enough and you know how to use it, most of the time you can make it do what you want - like for example using keyboard shortcuts and the clipboard to read the text from an unsupported GUI control. This is one advantage of tools that offer the flexibility of a real programming language for scripting.
There are also such things, for which you can not do much except waiting for the vendor to provide you a fix, and this can take long time. A few years ago I tried to upgrade to the latest TestPartner version (it was 5.2.3 back then). After the upgrade I found that all my automated scripts were causing random crashes in Internet Explorer. I just stayed with the old version until 5.6 came out, where this problem was fixed.

Recording does not work, even with IE

 I realized that I was not fair in my previous test,  as I used the last version of Firefox, which unfortunately is not officially supported by TestPartner. To give it a second chance, I decided to repeat the test with Internet Explorer.  I re-recorded the same scenario, but this time in IE and tried to replay it.

 I got a better result, but only slightly. The recorded script was able to log-in, but could not click the button to create a new mail:

The playback failed at step 12, where the tool tries to ‘Attach’ to an HTML frame, identified with ‘Name=c36gxk9p2bo3a’. Attaching to a UI control in TestPartner means simply declaring that the subsequent actions in the script will be executed within this control.  c36gxk9p2bo3a is a generated name which changes each time when you enter GMail.  This was the reason the script could not find the frame, when trying to replay.

 If I had to code this script by hand, I would omit this step altogether. Usually it is sufficient to only attach to the browser window and not to specific frames within it. Also, I would not locate the other controls by ID and screen coordinates as the recording did in steps 13 and 14. This will likely fail too, even if the problematic step 12 is fixed.