VisualWorks Testing Plugin Reference/en
Introduction
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)
- record/playback
- execute code inside the VisualWorks image
Preparation
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
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.
GUIBrowser Integration
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 possibly a port number (unless you started the expecco bridge inside the VisualWorks image in a port different from its default, 8881):
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:
Work in Progress
This is preliminary information; the plugin is being developed and major changes are to be expected. For example, currently the whole composite widget tree is presented (incl. all wrappers), which makes the element hierarchy often quite big and confusingly complex. We are working on schemes to hide irrelevant wrappers.
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.