Here’s the updated documentation link (if it doesn’t move again).

In other news, there is now a Groovy formatter for Selenium IDE, and support for a special GroovySeleneseTestCase which makes it possible to merge *AndWait commands into single commands. For example:

clickAndWait | foo

with the Java formatter translates into:

selenium.click("foo");
selenium.waitForPageToLoad("30000");

while the Groovy formatter simply says:

selenium.clickAndWait("foo")

Cleaner, and more expressive.

It should be now.

If you build from r2291 or greater from the RC trunk, you can play with it. Basically, the extension Javascript must be specified before the browser is launched, and stays in-play until the session is closed. A sample test has been checked in here:

SessionExtensionJsTest.java

This probably doesn’t work for proxy injection mode yet.

Happy extending!

Update

It appears too easy to encounter the “414 Request URI Too Large” issue. I’m looking into this.

Update

Looks like the 414 issue is related specifically to the Perl driver (see this Clearspace post); I noticed it when using Perl, but did not see the issue when running an equivalent test in Groovy:

import com.thoughtworks.selenium.*

class URILengthTest extends GroovyTestCase {
    def selenium

    @Override
    void setUp() {
        selenium = new DefaultSelenium('localhost',
            4444, '*firefox',
            'http://alistapart.com')
    }

    @Override
    void tearDown() {
        selenium.stop()
    }

    void testURILength() {
        def extensionJs = new File(
            'selenium-core/src/main/resources/core/scripts/ui-map-sample.js').text

        selenium.setExtensionJs(extensionJs)
        selenium.start()
        selenium.open('http://alistapart.com')
        selenium.click(
            'ui=allPages::section(section=topics)')
        selenium.waitForPageToLoad('5000')
    }
}

Update

Unfortunately, the 414 issue also affects the Python and Ruby client drivers (I just tested and verified this). I’m not about to fix them right this moment, so it appears the you can only truly take advantage of the per-session extension feature (i.e. include extensions of arbitrary size) in Java and Groovy for now. The good news is that this issue has already been reported, and JIRA tickets created (SRC-319 for Perl, SRC-321 for Python, SRC-322 for Ruby, and others for C# and PHP).

Thought I’d also expose the tool I mentioned earlier that I’ve been using to find the places to optimize. You can play with the jsprofile sample tests now without checking out any code. Cool!

Keep in mind that the sample Google News page contains very old news.

I ran a brief test using the same XPath I’ve been using for a while, on a snapshot of the Google News page, comparing IE7 against Firefox2. I used ajaxslt 0.8 . The results are quite interesting, download here in OpenOffice format: Ajaxslt Profiling Results

If my profiling results are correct (I acknowledge more rigor is possible (the “a script is running for a long time” dialog popped up several times when I was profiling IE7, taking some time to dismiss), but I just wanted to perform a quick test), several important trends are evident.

First, IE7 is way way slower than Firefox. But we knew that.

Second, the results don’t equivocate about which method calls are taking the longest. The top four worthy of consideration for optimization are (in order of total time consumed): xPathStep, ExprContext, BooleanValue, and copyArray.

Third, the average own time for xPathStep is grossly larger in IE than in Firefox; 5.18ms, versus only 0.22ms.

Finally, perhaps the most surprising result is that the number of method calls differed on the browsers, even though the XPath used was exactly the same. Shockingly, both ExprContext and BooleanValue had 20x more invocations in IE! Are these extra calls really necessary? Are they an artifact of my still-maturing profiler code? I hope we can determine the potential for optimization here is real.

Update

It appears that the profiler (not surprisingly) misses a few key methods: compare, clone, and evaluate. I’ll have to look into it more, but my hunch is that these are either added dynamically or are added to object prototypes, which the profiler currently may not be able to detect. Out of curiousity, I profiled the profiler itself running the ajaxslt test, using Firebug. This is what revealed the missing methods, whose timings are likely the main contributors to xPathStep.

It was interesting to observe the average time for the profile entry and exit functions. Obviously, these can impact the accuracy of the results. The average time for both added together was about 0.02ms . In comparison, the average times for compare, clone, the longest running evaluate (there are several), and copyArray were 0.463ms, 0.048ms, 0.573ms, and 0.03ms, respectively.

I’ll see if I can get the profiler to automatically capture those missing methods. I’ve added the Google News test to the repository, so you can try it and see for yourself.

The IDE seems destined to grow a map editor too. I think this would work splendidly well with UI-Element.