You might not know that Selenium provides a feature which allows you to capture the network traffic during a test. This might be handy in some cases - for example if you want to check the HTTP response headers returned by the server for some reason or to verify that a specific HTTP request is triggered during a test. I use it for example to verify that a web analytics request is properly triggered on a particular web page.
To use this feature you must start your tests by providing a special option to the start method, i.e.  selenium.start("captureNetworkTraffic=true");

Another useful Selenium feature I use is the ability to start the RC server by providing a specific Firefox profile for running the tests. Your normal Firefox settings are not used when running tests in *chrome mode. If you want to have a specific Firefox plugin active, or if for example you must use a proxy to access the tested pages, you have to use the -firefoxProfileTemplate setting when starting the Selenium server and provide the path to a custom Firefox profile folder that contains all the settings and plugins you want to use.

The problem is that those two features do not work together - when I use the captureNetworkTraffic=true option, I always get some generic Firefox profile and not the one I provide in the firefoxProfileTemplate parameter.

Here is my workaround for this problem. It turns out that inside the Selenium RC server jar there is a folder called customProfileDirCUSTFFCHROME, which contains the small generic firefox profile, used in this case and probably also in the case when you don't provide a custom Firefox profile.

If you want to capture the network traffic and still use a custom Firefox profile,  here  is how you can hack your selenium-server.jar to include a  custom profile.

• Extract the customProfileDirCUSTFFCHROME folder from selenium-server.jar
• Close all Firefox processes. Start Firefox with the -profilemanager option.
• Choose 'Create Profile' from the dialog that appears, click 'Choose Folder' and select the folder extracted  from the jar file.This way you will use the profile provided by selenium as a starting point. You can then make configuration changes, add plugins etc.
• When you exit firefox, pack all the changed files from the extracted profile folder back into the jar file. Now selenium will always use your custom profile

I tested this with Selenium 1.0.3. Works like a charm.

Having used the 1.0.3 version of Selenium RC for several weeks  I now have an overall impression of the new release. The thing that bugged me most was that the upgrade was not as smooth as I hoped  - several tests that previously worked fine with 1.0.1  started to fail with 1.0.3.  We were able to relatively quickly  find workarounds for what seem to be bugs introduced in the new release. Here are two links to the Selenium issue database  in case you run into the same or similar problems - 400 and 408; look for 'XHR ERROR' exceptions in your logs when opening URLs.

With the workarounds our tests became as stable as before – not better and not worse. The new version did not really bring any noticeable improvements for me – I have not yet moved to Firefox 3.6 and I am not a Mac user. So my advise would be – If you have your tests running smoothly on 1.0.1 and you don't need Snow Leopard and/or FF 3.6 support yet, don't bother upgrading for now.  There might be a new release on the horizon.

XPather is a small Firefox extension, which I find indispensable (together with Firebug) when writing Selenium tests.

It adds a 'Show in Xpather...' item to the context menu for all the UI elements on the web page. When selected this option opens a small 'XPather Browser' window showing a very, very long XPath expression which selects the element you chose.

Like /html/body/table[2]/tbody/tr[2]/td[2]/div[@id='login']/form[@id='gaia_loginform']/div[@id='gaia_loginbox']/table/tbody/tr/td/div/table[@id='gaia_table']/tbody/tr[8]/td[2]/input, which is the expression you get when you select the 'Sign in' button on the login page of Gmail. Of course you can write your own expressions and test to see what is selected on  the page.  So you can opt to use for example //input[@name='signIn'], which is much shorter and better way to locate the same button. I use XPather mostly to interactively test complex expressions whenever I am trying to locate some hard-to-find object on the web page.

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]);

 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.