Difference between revisions of "VisualWorks Testing Plugin Reference/en"

From expecco Wiki (Version 2.x)
Jump to navigation Jump to search
 
(3 intermediate revisions by the same user not shown)
Line 36: Line 36:
 
ExpeccoBridge startServiceOnPort:8881
 
ExpeccoBridge startServiceOnPort:8881
 
(all of the above being equivalent)
 
(all of the above being equivalent)
  +
  +
In expecco, you have to configure the connection (in "Extras" - "Settings" - "Execution" - "External Script Interpreters" - "Smalltalk") as:
  +
  +
[[Datei:VWSmalltalkSettings_en.png|400px]]
   
 
== Code Execution ==
 
== 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 [[Expecco_API/en#Bridged_Smalltalk_Elementary_Blocks | Bridged Smalltalk Elementary Blocks API Documentation]].
+
You can create elementary VisualWorks action blocks ("VW actions"), 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 [[Expecco_API/en#Bridged_Smalltalk_Elementary_Blocks | Bridged Smalltalk Elementary Blocks API Documentation]].
   
 
[[Datei:newVWSmalltalkAction_de.png|200px]]
 
[[Datei:newVWSmalltalkAction_de.png|200px]]
   
enter code to be executed inside the VisualWorks image:
 
  +
The instantiated action will execute a dummy default action, whichz simply outputs some text onto the (expecco-) Transcript (not the remote Smalltalk's Transcript). Make sure to show the expecco console ("Extras" - "Tools" - "Transcript") before you run this action.
  +
  +
You can change the code, for example to open a new application inside the VisualWorks image:
   
 
[[Datei:NewVWSmalltalkActionCode1.png|450px]]
 
[[Datei:NewVWSmalltalkActionCode1.png|450px]]
   
VisualWorks action blocks allow you to open additional windows, to interact with custom interfaces, custom widgets or to start background processes inside VisualWorks.
+
The VW-action will be executed inside your VW image. Thus, these blocks allow you to open additional windows, to interact with custom interfaces, custom widgets or to start background processes inside VisualWorks. It is also possible to interact with model objects, as long as you provide some accessors as class methods (of course, as a Smalltalker, you can get any object eg. with "someClass allInstances do:[...]"; however it is less obscure, if you use concrete getter methods).
   
 
== GUIBrowser Integration ==
 
== GUIBrowser Integration ==

Latest revision as of 15:12, 26 June 2020

Problem Statement[edit]

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 bitmap image comparison to find elements and OCR (optical character recognition) and to extract semantic data (text contents) from the VW user interface.

Typical UI inspection tools will present VisualWorks application windows as shown in this screenshot (which shows what WindowsAutomation sees):
VW in GuiBrowser WA.png
as you can see, VisualWorks looks to the outside world as a single big window - no input fields, buttons, lists etc. are visible.


The "Expecco VisualWorks Testing Plugin" solves this problem.

Introduction[edit]

The VisualWorks plugin interfaces to running VisualWorks applications via the expecco bridge protocol, which is based on the common bridge protocol described here .

The plugin provides the following functionality:

  • explore the UI in the expecco GUI browser (the widget hierarchy)
  • present, read and verify properties of individual widgets
  • retrieve selections, contents of text, bitmap and other semantic values
  • interact with VisualWorks UI components (simulate user interactions) by xpath locators
  • record/playback
  • execute code inside the VisualWorks image (see Expecco API)
  • provide extension mechanisms for custom widgets
  • interact with multiple visualworks or non-visualworks applications simultaneously

Preparation[edit]

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. Older VisualWorks versions do not support a script command line argument.

The expecco bridge code is a separate package (parcel), 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)

In expecco, you have to configure the connection (in "Extras" - "Settings" - "Execution" - "External Script Interpreters" - "Smalltalk") as:

VWSmalltalkSettings en.png

Code Execution[edit]

You can create elementary VisualWorks action blocks ("VW actions"), 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.

NewVWSmalltalkAction de.png

The instantiated action will execute a dummy default action, whichz simply outputs some text onto the (expecco-) Transcript (not the remote Smalltalk's Transcript). Make sure to show the expecco console ("Extras" - "Tools" - "Transcript") before you run this action.

You can change the code, for example to open a new application inside the VisualWorks image:

NewVWSmalltalkActionCode1.png

The VW-action will be executed inside your VW image. Thus, these blocks allow you to open additional windows, to interact with custom interfaces, custom widgets or to start background processes inside VisualWorks. It is also possible to interact with model objects, as long as you provide some accessors as class methods (of course, as a Smalltalker, you can get any object eg. with "someClass allInstances do:[...]"; however it is less obscure, if you use concrete getter methods).

GUIBrowser Integration[edit]

Connecting[edit]

Assuming that the expecco bridge is already running in your VisualWorks image, open the GUIBrowser tab,

OpenGuiBrowser.png

and connect to the VisualWorks image via the connect-"Smalltalk" dialog:

GuiBrowserConnectSmalltalk.png

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):

GuiBrowserConnectSmalltalk2.png

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 executed and tested individually:

GuiBrowserVisualWorks1.png

Wrapper Hiding[edit]

In the above example, a huge number of wrappers are shown, which are usually not very interesting for testing. Wrapper display can be enabled/disabled via the connection's popup menu.
Hiding is enabled by default.

With wrapper-hiding enabled, the tree looks much nicer:

VWGuiBrowserWithHiddenWrappers.png

Locating Widgets by XPath[edit]

VisualWorks widgets are referred t ousing an XPath locator. Notice, that the XPath implementation (inside the VW image) supports a subset of the full XPath feature set, and that (currently) the verbose syntax (i.e. like "/child::tag") is not supported.
Supported 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[edit]

//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[edit]

The VisualWorks UI framework has a number of weaknesses which may affect expecco.

Blocking UI Interface[edit]

Older VisualWorks versions (pre 8.x) 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).

Pointer Position only with Focus[edit]

VisualWorks seems to only be able to report the current mouse position when any of the VW windows has the focus (is active). This is known to happen in 7.x versions and may or may not happen in newer versions.
Whenever the focus is given to a non-VW window, the last known pointer position is reported. This affects the "Follow Mouse Pointer" operation.

No Unique Widget Identification[edit]

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 (parts of) the hierarchy-path, instead of a single automationID.

To better support automatic tests, VW-application programmes should 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 over releases and language versions and it should be unique; especially, it should NOT be a dynamically generated sessionID. It is recommended to add either a hierarchical ID (such as 'myApp.fileList') or a UUID to relevant widgets in your application's postbuild method. Then, test actions can refer to those widgets via:

//Button[@automationID="..."]

and become much more robust against changes in the layout (hierarchy) of the application.

Work in Progress[edit]

This is preliminary information; the plugin is being developed and major changes are to be expected.



Copyright © 2014-2020 eXept Software AG