views:

53

answers:

1

We're using Selenium for smoke-testing a Java Spring MVC based website. We invoke it using JUnit and the Java Selenium client. Much of the time, our tests work fine, but we tend to get timeouts in selenium.waitForPageToLoad in apparently random places. (That is, run the test suite multiple times and the location and number of timeouts will vary greatly.)

Running it with the server in the foreground, I can watch the tests executing. When one of these timeouts occurs, the selenium.click that preceded the wait has occurred but the wait doesn't appear to notice. Right-clicking on the page and selecting Refresh appears to clear the blockage.

To me, this suggests there's a race condition occurring between the click and waitForPageToLoad. Others have related problems with waitForPageToLoad but don't appear to describe a race condition. Some have suggested problems with the preceding selenium.click call, but I'm not seeing that here. Has anyone else seen what I've observed?

I've seen a number of suggestions to not use waitForPageToLoad, but the work-arounds often suggest using waitForElementPresent or manually polling for element presence. With our application that would seem to require instrumenting the HTML with IDs that would only be used by the tests. Is there a non-intrusive work-around to this method?

A: 

Selenium's waitForPageToLoad() function is quite reliable - I don't know why anyone would suggest that you shouldn't use it. It works particularly well in Firefox, where Selenium RC adds a plug-in that helps it detect the page-ready state, but it works just fine in Internet Explorer as well. We use it several thousand times in our test suite, and it never fails.

The question you should be asking is "Why is my page-wait timing out?" That's a problem best answered by capturing the network traffic involved in a test and analyzing the results when it fails. If you have a repeatable test case, WireShark or Fiddler are good tools. If not, you may have some luck using Selenium RC's captureNetworkTraffic() method in your exception handler to save the traffic on failure.

Ross Patterson
While looking at this, I've gotten so MAD at Windows for being unable to snoop localhost traffic through Wireshark.Anyway, I was able to track this down to the page readyState occasionally only reaching INTERACTIVE, meaning the waitForPageToLoad will never fire! This only seems to happen occasionally and I'm somewhat at a loss as to how to proceed.
Alan Krueger
@Alan: No argument from me re: Windows Wireshark localhost stupidity.
Ross Patterson
@Alan: Re: readyState: Dig deeper with something that captures your browser's network traffic - Fiddler is a good answer for Firefox. I expect you'll find that the page actually isn't *completely* ready - that there's some resource the browser's trying to load that isn't arriving in a timely fashion.
Ross Patterson