Interface PortableAutoTests
Writing AutoTests for multiple environments
Smart GWT has powerful features for integrating with a variety of third party testing tools. See theAutomated Testing overview
for an
overview of how to use testing tools with Smart GWT. The AutoTestLocator
system ensures that user interface elements can be
reliably identified when recording or playing back tests independently of the DOM structure
generated by Smart GWT components. Using locators insulates developers from changes to the
generated DOM structure due to different Smart GWT builds, different browsers and different
skins.
See the documentation topic ReliableLocators
for
best practices with respect to building applications that will generate robust and reliable
locators.
The AutoTest system also has some advanced features to facilitate recording and playing back tests across environments with significant differences including:
- Different data: multiple environments with different data sets (for example, test vs staging vs production)
- Embedded UI: your application or user interface may be embedded within a larger application or portal
- Per-User presentation: an application may present the same functionality differently per user. For example if an application has separately licensable modules, the user interface to navigate to some functional area may differ depending on which modules are available to the user
- Customer customizations: an application may allow users to add additional UI or rearrange screens
AutoTest variables
The variables
feature allows developers to specify
explicit variable names and corresponding values for use when resolving AutoTest locators.
Variables may be used anywhere within a locator string, but a common use case would be handling different data in different deployments. For example the locator for a ListGrid cell element might be as follows:
//ListGrid[ID="countryList"]/body/row[pk=47||countryCode=WS||countryName=Western%20Samoa||2]/col[fieldName=countryName||1]
This locator includes various fallback attributes to identify the row and column (see the
AutoTestLocator overview
for information about
fallback attributes in locator segments).
If you want to identify the cell by primary key field value and column name only, this could be simplified to be just:
//ListGrid[ID="countryList"]/body/row[pk=47]/col[fieldName=countryName]
In a
different data set, the equivalent record might have a different primary key field value,
meaning any locators that referenced it via hardcoded values like pk=47
would fail
to resolve to the correct target. This can be handled by setting up an AutoTest variable before
the test executes - for example recording the target record as testRecord
, and
referring to it directly in the locators:
//ListGrid[ID="countryList"]/body/row[pk=${testRecord.pk}]/col[fieldName=countryName]
AutoTestLocator root
The testRoot
attribute allows developers to designate some component as the "root" for an
autoTest. With this setting in place, locators for elements anywhere within that root
component will be generated as a path from the testRoot to the target component. These locators
will always start with the special prefix //testRoot[]
.
If the same UI
elements are then rendered inside another container in a different environment, configuring
testRoot
to point to this container will
allow the locators to resolve correctly.
If no global testRoot was specified, any component
with an explicit ID
will be treated as the
root component for the elements it contains. This means that locators for components with
explicit IDs will resolve correctly regardless of where these components are in the page's
structure.
Components with an explicit ID are located by ID and widget class name by
default. You can also set Canvas.locateByIDOnly
- this will cause the generated locator for the component to omit the
widget class name altogether and create a very compact locator of the format
///componentID