The acronym AJAX for "Asynchronous Javascript and XML" is generally associated with modern web applications that provide a more interactive look and feel than classical <FORM> based applications, almost comparable to desktop applications. Behind this common acronym there is a whole zoo of toolkits that drive those applications, each with different key aspects and unique widget sets. Such toolkits pose a problem for QF-Test and in fact any automated testing tool for several reasons:

• The actual component hierarchy is created automatically from abstract widgets like Buttons or Lists. Often each widget is implemented as a number of <DIV> nodes. This leads to very deeply nested hierarchies with very little structure.
• Ids are either not assigned at all or automatically created and thus worse than useless.
• The asynchronous communication with the web server and dynamic creation of DOM nodes may cause timing-related problems.

There is no panacea to address these problems in a generic way. In most cases QF-Test can interact with AJAX applications out-of-the-box, but component recognition and performance are not ideal. Optimal testability can only be achieved with special case handling that exactly fits a given toolkit and takes advantage of its peculiarities.

An AJAX resolver is a set of resolvers and other methods implemented specifically for a given AJAX toolkit. Most notably QF-Test tries to assign individual classes matching the high-level widgets to DOM nodes and remove intermediate nodes that are just an implementation detail. 'Name', 'Feature' and 'Extra feature' attributes are determined in a way suitable for the toolkit and events are simulated on the correct DOM node in a way that most closely matches user interaction. These measures drastically reduce the component hierarchy and increase the reliability and performance of component recognition and replay. Timing and synchronization are also addressed.

As a necessary consequence the components and events recorded for a given web application vary drastically with and without an active AJAX resolver and are not compatible with each other. Thus the decision whether or not to use an AJAX resolver should be made as early as possible, otherwise tests will either need to be reimplemented after activating the resolver or tests with and without resolver must be cleanly separated. If a resolver is available for your application you should practically always use it. The only exception is if the existing test-base is already too large, mostly complete and stable.

Implementing AJAX resolvers is an ongoing process. As changes to a resolver can have consequences in terms of how components are recorded and recognized we need to make sure that you can update your QF-Test version without losing backwards compatibility with existing tests. To that end, AJAX resolvers have their own three-digit versioning scheme, starting with version 1.0.0, with the following meaning:

• A change in the minor version, e.g. 1.0.1, means that compatibility is not affected.
• Medium version changes, e.g. 1.1.0, imply that tests recorded with a lower medium version should still replay, but recording additional sequences may record components in a different way. This is not critical, but you may want to avoid it in case the benefits of the newer version don't outweigh it.
• A major version change, e.g. 2.0.0, can be incompatible even for replay so that manual updates or new recording of the affected components may be required.

AJAX resolvers are activated via the 'Procedure' qfs.web.ajax.installToolkitResolver in the standard library qfs.qft where you have to provide the version to use. You can choose to specify only the major version, in which case QF-Test uses the latest medium.minor version available for this major version. This is normally the best option and used in the SUT startup sequences created with QF-Test's quickstart wizard (see chapter 3). Alternatively you can specify major.medium version or even major.medium.minor to use an exact version and thus run your tests with the resolver version with which they were created.

Unfortunately the number of available AJAX toolkits keeps growing rapidly and popularity changes frequently so we have to weigh carefully which toolkit to support and to which degree. Cooperation with QF-Test users also plays a major role. Resolver development may also be frozen - except for critical bug fixes - if a toolkit loses relevance.

This section lists the supported AJAX toolkits and versions with the available resolver versions. Newer toolkit versions don't necessarily require an update of the resolver. If your application uses a newer version of the toolkit than the supported versions listed below, please use the latest AJAX resolver available for this toolkit and let us know about your results.

The Google Widget Toolkit has been supported starting with GWT version 1.5. A GWT demo test-suite, tested against GWT version 2.3, is provided in the file .../demo/web/gwt.qft. This demo makes use of generic components and provides several useful procedures for working with some common GWT widgets.

The resolver was initially created for Ext JS version 2, preliminary testing wit Ext JS version 4.0.1.

There is no separate Ext GWT resolver. Ext GWT is in fact a combination of Ext JS and GWT and QF-Test supports it by installing both the Ext JS and the GWT resolver.

The resolver was developed against RichFaces versions 3 and 4.

The resolver was developed against qooxdoo version 0.7.2. Currently not under active development.

The resolver was developed against RAP version 1. Support for RAP version 2 and higher is incomplete. Currently not under active development.

Vaadin is another toolkit that is based on GWT but comes with additional features and its own widget set. A resolver for Vaadin is under development. If interested, please get in touch.

jQuery UI appears to be the rising star among current AJAX toolkits. A resolver for jQuery UI is under consideration. If interested, please get in touch.

Last update: 04/23/2012 Copyright © 1999-2012 Quality First Software GmbH