While testing websites the response time of a page can be troublesome for the automated tests. Additionally JavaScript and/or page redirections can mean the page doesn't finish loading in the first request. To further complicate this some of the backends (like Selenium) cannot reliably detect when a page is even finished loading.

In order to understand this content please always refer to asynchronous loading and waiting commands→.

In some cases you may be forced to wait until a page, or AJAX, request has completed before continuing. While in the general case this isn't required, it is supported for those cases where it is. The below method gives the best option known to date.

End of Page Markers

In many situations, which you've likely already encountered, the application being tested will have to be modified to allow automated testing. In order to detect the end of the page you will thus need to make the program emit an end of page marker.

If your application already has a common element at the end of the page this can be used to detect the end of the page. Otherwise a span element is a good choice.

<span id='end-of-page' title='12'/>

To detect, and wait, for this marker to appear you could then do a Check statement, like below, but...

Check //span[@id='end-of-page']

...it won't quite work as expected.

Incremented Values

You'll notice our example span contained a number in the title attribute. It is expected that the application will increase this number for every request in the same session, so that each request has a higher number than the last.

This is important since when you do your Check command you need to ensure you are waiting for the element in the new page, and not matching on whatever page your are currently on. This scenario is quite common for slow, or JavaScript driven sites.

Having an incrementing number allows you to work around this. You simply use an XPath which checks the tag and the title value.

Check //span[@id='end-of-page'][@title>%LogicalRoot:OldPage%]
set %LogicalRoot:OldPage% %Response://span[@id='end-of-page']/@title%

AJAX and Other Dynamic Pages

This same technique can be extended to any part of a page that is dynamic. You simply have to follow the marker and counter logic. This is the most generic solution available which doesn't involve any backend trickery to detect page loading.

Verify Example

To get this working on all of your pages it is best to put the code in one of our root verify scripts. Then anytime you call Verify→ you will automatically invoke this code. This has the nice side-effect that after the Verify→ returns you'll know the next page has finished loading.

A complete example for a state hierarchy Web might look like the below.

if exists %LogicalRoot:Web.PageCount%
  Check //span[@id='end-of-page'][@title>%LogicalRoot:Web.PageCount%]
else
  # Not yet set, so just look for any end marker
  Check //span[@id='end-of-page']
end

set %LogicalRoot:Web.PageCount% %Response://span[@id='end-of-page']/@title%

At any point if you need to restart the counter, and are not creating a new logical root, simply reset the counter before calling verify.

reset %LogicalRoot:Web.PageCount%

Alternate Approaches

Over several years many different approaches were tested to accomplish the same thing. All options, other than the above, ultimately failed for one reason or another.

Initially, when using HTTPUnit as a backend, the pages all loaded synchronously so it wasn't an issue at all. And now, using HTMLUnit that option is still available, but it doesn't help resolve dynamic pages with JavaScript. Additionally it simply isn't supported in Selenium.

Looking for //body also seemed like a good idea since until the body element was complete the element would not appear. At first this worked well, until we realized Firefox will in certain cases happily expose an incomplete body element.

It should be stressed that normally waiting for the end of the page is not necessary. It only becomes truly needed in a rather complex setup with many verification scripts, CheckNot commands and/or soft checkpoints. The normal element waiting logic in TestPlan usually removes the need to have explicit load waiting.