VisualWorks Testing Plugin Reference/en: Unterschied zwischen den Versionen
Cg (Diskussion | Beiträge) |
Cg (Diskussion | Beiträge) |
||
Zeile 2: | Zeile 2: | ||
Graphical VisualWorks ("VW") applications do not use "proper" windows to represent widgets such as buttons, input fields etc. Thus, most UI automation and testing tools will not be able to automate VisualWorks applications on a logical widget level. Instead, they will see a single window, and you have to navigate to widgets by position offset or image detection mechanisms. They will also no be able to extract attributes (such as selection index, text contents, enabled state etc.), and you have to use mechanisms like OCR (optical character recognition) and bitmap image comparison to extract semantic data from the VW user interface. |
Graphical VisualWorks ("VW") applications do not use "proper" windows to represent widgets such as buttons, input fields etc. Thus, most UI automation and testing tools will not be able to automate VisualWorks applications on a logical widget level. Instead, they will see a single window, and you have to navigate to widgets by position offset or image detection mechanisms. They will also no be able to extract attributes (such as selection index, text contents, enabled state etc.), and you have to use mechanisms like OCR (optical character recognition) and bitmap image comparison to extract semantic data from the VW user interface. |
||
The |
The "Expecco VisualWorks Testing Plugin" solves this problem. |
||
= Introduction = |
= Introduction = |
Version vom 15. Mai 2020, 09:54 Uhr
Inhaltsverzeichnis
Problem Statement[Bearbeiten]
Graphical VisualWorks ("VW") applications do not use "proper" windows to represent widgets such as buttons, input fields etc. Thus, most UI automation and testing tools will not be able to automate VisualWorks applications on a logical widget level. Instead, they will see a single window, and you have to navigate to widgets by position offset or image detection mechanisms. They will also no be able to extract attributes (such as selection index, text contents, enabled state etc.), and you have to use mechanisms like OCR (optical character recognition) and bitmap image comparison to extract semantic data from the VW user interface.
The "Expecco VisualWorks Testing Plugin" solves this problem.
Introduction[Bearbeiten]
The VisualWorks plugin interfaces to running VisualWorks applications via the expecco bridge protocol, which is based on the protocol described [ Embedded_Systems_C_Bridge_API#Bridge_Wire_Protocol | here ].
The plugin provides the following functionality:
- explore the UI in the expecco GUI browser (the widget hierarchy)
- interact with VisualWorks UI components (simulate user interactions) by xpath locators
- record/playback
- execute code inside the VisualWorks image (see Expecco API)
Preparation[Bearbeiten]
The VisualWorks image must have the expecco bridge code installed and running. For this, it must either be started with a script (command line argument) to load the expecco bridge code upon startup, or it must have been deployed with the bridge parcel already installed.
The expecco bridge code is a separate package, provided by exept.
Once loaded, the expeco bridge should be started inside VisualWorks with one of:
ExpeccoBridge startService ExpeccoBridge startServiceOnPort:(ExpeccoBridge defaultPort) ExpeccoBridge startServiceOnPort:8881
(all of the above being equivalent)
Code Execution[Bearbeiten]
You can create elementary VisualWorks action blocks, which contain VisualWorks Smalltalk code. These will be executed inside the VisualWorks image. This is similar to remote Smalltalk/X code execution and the API is described in the Bridged Smalltalk Elementary Blocks API Documentation.
enter code to be executed inside the VisualWorks image:
GUIBrowser Integration[Bearbeiten]
Assuming that the expecco bridge is already running in your VisualWorks image, open the GUIBrowser tab,
and connect to the VisualWorks image via the connect-"Smalltalk" dialog:
In the dialog, enter the host name (of where the VisualWorks image is running), and a port number (the default for VisualWorks connections is 8881, unless you started the expecco bridge inside VisualWorks on another port):
When connected, the usual widget tree is shown; when selected, a widget's attributes are shown in the middle pane, and actions can be selected from the action list and recorded or tested individually:
In the above example, a huge number of wrappers are shown, which are usually not very interesting for testing.
Wrappers can be optionally hidden (via the connection's menu).
Hiding is enabled by default.
With wrapper-hiding enabled, the tree looks much nicer:
Locating Widgets by XPath[Bearbeiten]
VisualWorks widgets can be referred to via an XPath. Notice, that the XPath implementation supports a subset of the full XPath feature set, and that (currently) the verbose syntax (i.e. like "/child::tag") is not supported. Possible XPath constructs are:
// - deep wildcard /*/ - single element wildcard /../ - parent /tag/ - child(ren) with that tag /tag[idx]/ - child with idx /tag[@attr='attrVal']/ - child(ren) with attribute /tag[starts-with(@attr,'prefix')]/ - child(ren) with function on attribute
and combinations of the above:
/*[@attr='attrVal']/ - any widget type with attribute /MenuItem[@a1='val1'][@a2='val2']/ - a MenuItem with those attributes /*[@attr1='attrVal1'][1]/ - the first widget with that attribute
Functions supported are:
starts-with(@attr, prefix) ends-with(@attr, suffix) matches(@attr, pattern) contains(@attr, substring)
Examples[Bearbeiten]
//MenuBar[1]//MenuItem[@label="File"] - a MenuItem with label "File" under the first MenuBar //MenuItem[@label="File"] - a MenuItem with label "File" anywhere //*[@label="@label="System only"] - any component with that label
Problems[Bearbeiten]
Older VisualWorks versions have a serious bug in their UI interface, in that VisualWorks is completely blocked (at least on the Windows operating system) while a Window is moved or resized. As a consequence, no communication messages (on the bridge socket) are answered while the user is doing this, and expecco will think that the bridge connection is dead (timedout), and will eventually report a "broken connection".
If your application runs inside such a broken VW version, you should either set the alive timeout to a longer time (for example: 30 seconds) or disable it altogether. This can be changed globally in the settings dialog, or for a single connection in the GUI browser's connection popup menu.
This problem does not exist if you connect to an ST/X application, because the UI's window handling is completely decoupled from the other threads inside ST/X (and has been since 30 years).
Work in Progress[Bearbeiten]
This is preliminary information; the plugin is being developed and major changes are to be expected.
In addition it should be clear that the VisualWorks UI framework has a number of weaknesses, one of them being that UI elements do not have consistent automationIDs (in contrast to ST/X widgets, where the programmer may assign those). This means, that widgets (currently) have to be addressed via an xpath, which usually enumerates the path, instead of a consistent automationID.
To support automation, VW-applications can provide a unique id as a property of the component:
someComponent propertyAt:'automationID' put:<someUniqueID>
where <someUniqueID> can be a string or a UUID. Of course, the ID should remain constant - it should NOT be a dynamically generated sessionID.