expecco Wiki (Version 25.x) - Benutzerbeiträge [de]

WindowsAutomation Reference 2.0

2018-06-04T07:59:23Z

Lv: /* Preparing a remote system for test exeuction */

This is the documentation for the Windows Automation 2.0 plugin.

It provides facilities to automate tests incorporating applications with a GUI based on Windows Presentation Foundation (WPF), WinForms, and the old Win32 API.

=Features=
*Automated GUI testing of WPF, WinForms, and Win32 applications.
*Contains an expecco block library and tools which help to model tests and inspect the GUI of the application.
*Parallel remote test-execution on multiple systems.
*Performs tests against already built executables. No source code changes / recompilation of the application is required.
*Access to GUI components using XPath locators.
*Access objects of the application live at execution time.
*Full access to keyboard and mouse of the target system.
*Lots of additional features such as screen capturing, taking screenshots, highlighting GUI elements, mouse tracking, ...

=Installation and Connection=
The WindowsAutomation testing plugin uses the expecoo ".NET-Bridge" which consists of two parts: A plugin for expecco, and a server executable using the .NET framework running on the remote computer to connect to.

==Requirements==
On the machine running the system under test:
*.NET Framework 4.6.2 [https://www.microsoft.com/net/download/all] or higher.
* One of the following operation systems:
::- Windows 7 SP1
::- Windows 8
::- Windows 8.1
::- Windows 10

::- Windows Server 2008 R2 SP1
::- Windows Server 2012
::- Windows Server 2012 R2
::- Windows Server 2016
::- Windows Server, version 1709

==Plugin Components==
The plugin consists of the following parts:
* The GUI Browser, used to interactively explore your application.
* The Windows Automation Library, which provides blocks that you can use in your test cases.
* The .NET-Bridge server, which provides an interface between the application under test and your tests running in expecco.

==Installing and Configuring the Plugin in Expecco==
The plugin is usually installed automatically by the installer; either included in the main expecco installation or provided as a separate installable add-on package. Its files are stored in the "plugin" subfolder of the expecco installation folder. You can also copy those files manually to that folder, if required. Expecco detects the plugin automatically during startup. You might need to restart your expecco session.

==Preparing a local system for test execution==
If you want to automate an application running on the same host as expecco, there is no need to set up anything! Everything should work out of the box.

TODO: Is that still true with the gui browser?
TODO: Pictures for the connection process

==Preparing a remote system for test exeuction==
The remote system will have to run the ".Net-Bridge server" which in turn connects to expecco.
You just need to copy "DotNetBridgeServer.exe" to the computer your system under test is running on. No further installation is needed.

To start the bridge, navigate to the executable in a shell and start it with the following arguments:
{| class="wikitable"
|-
! Arguments !! Required !! Description
|-
| -s || Yes || Tells the executable to run in server mode (as opposed to client mode).
|-
| -k || Yes || Tells the client to keep the connection open after aconnection has been terminated. This saves you the hassle to restart it every time a test finishes.
|-
| -a <ip/hostname>|| Yes || The IP-Address of the PC your application is running on.
|-
| -p <int> || No || The port the server should listen on (default is 34318).
|}

=Settings=
TODO: What settings does the plugin have?

=GUI Browser=
The GUI browser allows you to explore a running application. You can browse the application, inspect element properties and execute actions. For a more detailed description also see [[Expecco GUI Tests Extension Reference|Gui Browser]].

=Library=
This article gives a short overview over the design philosophy of the library. You can find more detailed documentation and examples attached to the blocks itself.

== Connecting to an Application ==
To automate an application, you first have to connect to it. You can do this with the
blocks from the '''Connecting''' group.
[[Bild:WindowsAutomation2_Library_ConnectingBlocks.PNG|frame|The Library's Connection Blocks.]]

You can connect to an application by its '''executable name''', or by its '''process id'''.
If you use the executable name, expecco will attach to the main process of the specified executable. Be careful as this is not necessarily the process
drawing the GUI! Use the process id if an application spawns more than one process and you need to make sure you connect to the GUI process and not some background process.
All connection blocks also require you to specify a '''name''' by which the connection should be known in future.
This is needed for when you automate multiple applications at the same time and need to change
'''connection contexts''' during test execution.
Please note that the application to connect to has to be started before the corresponding connection block is executed.
You can change in context of which connection a block is executed with the '''Set Active Connection''' block.
This allows you, for example, to automate and compare the state of applications running on multiple systems in one test case.

=== Establishing a Local Connection ===
If you want to automate an application running on the same host as expecco, there is no need to set up anything! Just use the '''Create Local Connection''' with the mentioned above parameters.

=== Establishing a Remote Connection ===
Make sure that the DotNet Bridge server is started as explained in [[#Preparing a remote system for test exeuction]]
When the bridge is running, you can connect to it with the '''Create Remote Connection''' block using the hostname and IP-Address you specified when you started the bridge.

=== Closing a Connection ===
Remember to always close a connection when it is no longer needed, as it otherwise needlessly consumes resources.
One simple way to do this is to setup your connections in the '''Before Execution''' part of the test suite
and put the '''Close All Connections''' block in the '''After exeuction''' part.

 
== Accessing GUI Elements ==
[[Bild:WindowsAutomation_Library_AccessBlocks.PNG|frame|The Library's GUI Element Access Blocks.]]
[[Bild:WindowsAutomation_Library_AccessBlocksExamples.PNG|frame|A Few Examples on How to Access Elements in Notepad.]]
[[Bild:WindowsAutomation_Library_AccessBlocksModes.PNG|frame|Different Ways to Reference a GUI Element.]]
All Windows applications are built as a ''' tree''' of ''' GUI elements''' .
Some elements act as container of other element - their children. Tables, for example, are containers
for their cell elements which themselves might contain text labels.
At the root of the tree are one or more '''windows''' . When you connect to an application, you get access to
all windows at the tree's root.
To manipulate any of the system under test's GUI element, you first have to gain access to it.
The group '''GUI Element Access''' provides blocks that help you to gain access to the elements. There are 12 blocks in total, divided between ''' Access By XPath''' , '''Access By Property''',
and '''Existence Test'''. For each category, blocks with the same interface exist. The only difference is the method of retrival.

;Get GUI Element : returns a '''single''' GUI Element matching the search condition. If multiple match the condition, an '''arbitrary''' element matching the condition is returned.
:If you want to make sure that there is only one element matching, set '''ensureExclusive''' to true. You can also enforce this globally by setting the environment variable '''ensureExclusive''' in your environment.
:If ensureExclusive is set and more than one element is found, the block will fail and notify you of the ambiguity. This is disabled by default as checking for uniqueness is a very costly operation.
:You can also specify a '''timeout''' after which the search is aborted. This is useful if you know an element should be there soon but might currently be loading.

;Get GUI Elements: returns '''all''' GUI Element matching the search condition. If no element is found, it returns an empty list Timeout and cacheXPath are also applicable.

;Exists: Works exactly the same as '''Get GUI Element''' but does not fail if no element can be found. Additionally provides an output pin specifying if an element has been found.

Both of these blocks are also available in the '''Relative To Anchor''' variety. Those blocks also take a GUI Element as '''anchor''' in relation to which they search.

=== Using XPaths ===

'''XPath''' is the query language this plugin uses for selecting GUI elements in the application's element tree.
You can find the XPath of an element with the [[Expecco GUI Tests Extension Reference|Gui Browser]] or with third-party applications like Inspect.exe [https://msdn.microsoft.com/en-us/library/dd318521(v=vs.85).aspx] or FlaUInspect [https://github.com/FlauTech/FlaUInspect].
An '''XPath''' for the scroll button on the
vertical scrollbar in the german Windows Notepad application looks like this:

<code>/Window[@Name='Unbenannt - Editor']/Document[@Name='Text-Editor']/ScrollBar[@Name='Vertikale Bildlaufleiste']/Button[@Name='Bildlauf nach unten'] </code>

For each level in the GUI tree, a new Location Step containing the child elements Control Type has to be added.
You do not have to use any predicates, the following XPath is valid as well:

<code>/Window/Document/ScrollBar/Button </code>

but might lead to issues as there might be multiple GUI Elements matching this path.
You can select by three predicates that can be mixed and matched in the same query:

; Name: the name the application developer has given an element. Be careful as this name might change during programm execution (See for example Notepad's window name which always begins with the name of the currently opened file.
: <code>/Window[@Name='Unbenannt - Editor'] </code>

; AutomationId: An ID the application developer has given an element. It is meant to be unique between siblings but that is not enforced.
: Many developersleave the ID empty or reuse it, making it useless. You should nontheless use this ID wherever applicable as it is static
: and meant for this exact purpose.
: <code>/Window/Document[@AutomationId='15'] </code>

;List Index: If there are multiple siblings with the same Control Type, you can select one of them by (1-based) list index.
: <code>/Window[1]/Document[1] </code>
: <code>/Window[1]/Document[last()] </code>

'''Please Note''': You can '''only''' use the three predicates above in your XPaths. Other predicates '''DO NOT''' work! If you want to search
an element by another property (e.g. its help text), use the '''By Property''' variant of the block instead. If the property is not unique,
you can select a unique ancestor of the target by property or XPath relative to which the property is unique.
You can then use that ancestor as anchor in the '''Get GUI Element By Property (Relative to Anchor)''' block.

=== Using Wildcards in XPaths ===

XPath also supports '''wildcards'''. You can:
* replace '''one tree level''' with a "*" wildcard:
<code>/Window/Document[@AutomationId='15']/*/Button[1]</code> 
<code>/*/*/*/Button[1] </code>

* replace a '''control type''' with a "*" wildcard:
<code>/Window/*[@AutomationId='15'] </code>

* replace '''an arbitrary amount of tree levels''' with a "//" wildcard:
<code>//Button </code> 
<code>/Window//Button[1] </code>

Especially the last option is useful as it makes your tests more readable as the reader can easily focus on the relevant parts of the xpath.
But be careful. Using wildcards comes at a steep performance cost. If your tests run unacceptably slow, first try to '''remove wildcards where they are not needed'''.

=== Using Properties===

You can also search for elements by property by specifying a value an element's property with the given name must have. For a list of properties a GUI element might have, take a look at Microsoft's documentation [https://docs.microsoft.com/en-us/dotnet/framework/ui-automation/ui-automation-control-patterns-overview#control-pattern-classes-and-interfaces]. It specifies the supported properties for each pattern an element can support.

=== XPath Resolution in Action Blocks ===

Getting a reference to the GUI Element everytime you need to manipulate it in any way can make for very unclean looking test suites as two blocks are needed to perform any action - one for getting a reference to the element and another one for perform the action. The library therefore also allows you to directly feed an xpath into every block that would take a reference to a GUI Element.

The image on the right shows this mode in action. Variants 1 and 2 are functionally equivalent.
While Variant 2 is more concise, Variant 1 is the right choice in most cases. While it has an additional block, you have control over the other input parameters.
You also can recycle the GUI element reference as seen in 3). This is invaluable as the XPath only has to be resolved once. This speeds up test execution by a lot as XPath resolution is very expensive operation.

'''Rule of thumb''': Always use Variant 1 except if you need the reference to the GUI element only once.

 
== Interacting with GUI Elements ==
Once you retrieved a GUI element, you can interact with it by making use of the library's blocks located in the groups '''Elements''', '''Patterns''', and '''Properties'''.
Blocks in those categories take a GUI Element (and sometimes additional data) as input and manipulate it or query for its properties in some way.

[[Bild:WindowsAutomation_Library_ElementsPatternsProperties.png|frame|The Library's Blocks for Interacting With Elements.]]

=== The 'Elements' Group ===

This group contains blocks that are applicable to blocks that only work on '''GUI elements of a specific type'''. For a block's detailed description with examples ,
take a look at the block's documentation in expecco.

Even though not only Checkboxes can be 'checked', the '''Check''' block in the '''Checkbox group''' only works for checkboxes and not e.g. for radio buttons.
Because of this limitation there are not that many blocks targeting specific elements. Most blocks target a specific '''pattern''' instead and are therefore in the '''Patterns''' group.

=== The 'Patterns' Group ===

This group contains blocks that are applicable to GUI elements supporting a certain '''pattern'''. '''Patterns''' describe how a GUI element '''behaves''' rather than what it '''is'''. An element can also support multiple patterns
at the same time. You can find out which patterns an element supports with the '''Get Supported Patterns''' block or by taking a look at Microsoft's documentation about patterns [https://docs.microsoft.com/en-us/dotnet/framework/ui-automation/ui-automation-control-patterns-overview].

Pattern blocks can therefore be '''re-used''' between GUI elements of different types. The '''Expand''' block of the '''ExpandCollapse pattern''', for example, can be used to expand Comboboxes, Menus, Submenus, or Trees.

=== The 'Properties' Group ===

Blocks in the '''Patterns''' and '''Elements''' group already allow you to query the value of properties pertaining to that element or pattern. Blocks of the '''Properties''' group allow you to query properties all elements share as well as arbitrary properties. If you try to retrieve a property an element does not support, the block will fail.

Please note that the '''Get Arbitrary Property''' block can only query for properties that belong to a pattern. You cannot, for example, query "Text" from a textfield as this is not a property, use "Value" of the value pattern instead. Microsoft's documentation has a list of patterns and the properties they provide [https://docs.microsoft.com/en-us/dotnet/framework/ui-automation/ui-automation-control-patterns-overview#control-pattern-classes-and-interfaces]

 
== Automating Keyboard and Mouse ==
[[Bild:WindowsAutomation_Library_KeyboardMouse.png|frame|The Library's Blocks for Interacting With Keyboard and Mouse.]]

You can control keyboard and mouse with the blocks in the groups '''Keyboard''' and '''Mouse''' that can be seen on the right. In contrast to the blocks above which work in context of a GUI element, the keyboard and mouse blocks work on a global level. You therefore do not need to provide a GUI element when using them.

You might want to execute some blocks in context of a GUI elemenet nontheless (e.g. enter a number into a text field instead of just pressing keys while the application is running). You can achieve this by selecting the element with the mouse beforehand as you would do when using the application normally (use the '''Left/Double/Right Click On Element''' blocks for this).
If you do not want to wait for the mouse to move, you can also use the '''Set Focus''' block instead.

=== Keyboard ===
The plugin provides blocks interacting with the keyboard on different abstraction levels. The most versatile block is '''Type With Control Keys Pressed''' where you can specify a string of characters to be typed while any number of control keys (e.g. esc, alt, shift, ctrl, ...) are held down. All other blocks are specializations of this block.

'''Press Control Keys''' e.g. allows you to enter key commands such as renaming files (ALT+F2), starting the task manager (CTRL+ALT+DEL), or closing a window (ALT+F4). '''Press Control Key''' makes it easy to just press a single key (e.g. RETURN to start a new line in an edit box). The '''Shortcuts''' group provides an assorted collection of often used key combinations for your convenience.

Use the '''Type''' to just type some text or, if you just need some throwaway demo text, use '''Type Random Phrase'''.

If you need more fine grained control over the keyboard, you can make use of '''Scan Codes'''. The keyboard sends a scan codeto the operating system whenever a key is pressed or released.
Microsoft provides a list of the scan codes it supports [https://docs.microsoft.com/en-us/previous-versions/visualstudio/visual-studio-6.0/aa299374(v=vs.60)].
'''Press Key By Scan Code''' sends Windows a signal that a key with a given scan code has been pressed (and is held down). The matching '''Release Key By Scan Code''' sends Windows the adverse signal.
Please note that a key that is pressed, stays pressed until it is explicitly released. If you want to just press and release a key by scan code, use '''Type Key By Scan Code'''.

=== Mouse ===
The plugin provides blocks manipulating the mouse in three ways: '''Clicking''', '''Moving''', and interacting with its '''Buttons'''.

 
== Recording and Taking Screenshots ==

= Frequently Asked Questions =

== What is the difference between Click/Invoke/Select/Toggle? ==

== My element supports a certain pattern but blocks of that pattern don't work? ==

== I have designed custom elements, how can I automate them? ==

== I have extended my GUI elements to have custom properties, how can I query them? ==

WindowsAutomation Reference 2.0

2018-06-04T07:58:22Z

Lv: /* Keyboard */

This is the documentation for the Windows Automation 2.0 plugin.

It provides facilities to automate tests incorporating applications with a GUI based on Windows Presentation Foundation (WPF), WinForms, and the old Win32 API.

=Features=
*Automated GUI testing of WPF, WinForms, and Win32 applications.
*Contains an expecco block library and tools which help to model tests and inspect the GUI of the application.
*Parallel remote test-execution on multiple systems.
*Performs tests against already built executables. No source code changes / recompilation of the application is required.
*Access to GUI components using XPath locators.
*Access objects of the application live at execution time.
*Full access to keyboard and mouse of the target system.
*Lots of additional features such as screen capturing, taking screenshots, highlighting GUI elements, mouse tracking, ...

=Installation and Connection=
The WindowsAutomation testing plugin uses the expecoo ".NET-Bridge" which consists of two parts: A plugin for expecco, and a server executable using the .NET framework running on the remote computer to connect to.

==Requirements==
On the machine running the system under test:
*.NET Framework 4.6.2 [https://www.microsoft.com/net/download/all] or higher.
* One of the following operation systems:
::- Windows 7 SP1
::- Windows 8
::- Windows 8.1
::- Windows 10

::- Windows Server 2008 R2 SP1
::- Windows Server 2012
::- Windows Server 2012 R2
::- Windows Server 2016
::- Windows Server, version 1709

==Plugin Components==
The plugin consists of the following parts:
* The GUI Browser, used to interactively explore your application.
* The Windows Automation Library, which provides blocks that you can use in your test cases.
* The .NET-Bridge server, which provides an interface between the application under test and your tests running in expecco.

==Installing and Configuring the Plugin in Expecco==
The plugin is usually installed automatically by the installer; either included in the main expecco installation or provided as a separate installable add-on package. Its files are stored in the "plugin" subfolder of the expecco installation folder. You can also copy those files manually to that folder, if required. Expecco detects the plugin automatically during startup. You might need to restart your expecco session.

==Preparing a local system for test execution==
If you want to automate an application running on the same host as expecco, there is no need to set up anything! Everything should work out of the box.

TODO: Is that still true with the gui browser?
TODO: Pictures for the connection process

==Preparing a remote system for test exeuction==
The remote system will have to run the ".Net-Bridge server" which in turn connects to expecco.
You just need to copy "DotNetBridgeServer.exe" to the computer your system under test is running on. No further installation is needed.

To start the bridge, navigate to the executable in a shell and start it with the following arguments:
{| class="wikitable"
|-
! Arguments !! Required !! Description
|-
| -s || Yes || Tells the executable to run in server mode (as opposed to client mode).
|-
| -k || Yes || Tells the client to keep the connection open after aconnection has been terminated saving you the hassle to restart it every time a test finishes.
|-
| -a <ip/hostname>|| Yes || The IP-Address of the PC your application is running on.
|-
| -p <int> || No || The port the server should listen on (default is 34318).
|}

=Settings=
TODO: What settings does the plugin have?

=GUI Browser=
The GUI browser allows you to explore a running application. You can browse the application, inspect element properties and execute actions. For a more detailed description also see [[Expecco GUI Tests Extension Reference|Gui Browser]].

=Library=
This article gives a short overview over the design philosophy of the library. You can find more detailed documentation and examples attached to the blocks itself.

== Connecting to an Application ==
To automate an application, you first have to connect to it. You can do this with the
blocks from the '''Connecting''' group.
[[Bild:WindowsAutomation2_Library_ConnectingBlocks.PNG|frame|The Library's Connection Blocks.]]

You can connect to an application by its '''executable name''', or by its '''process id'''.
If you use the executable name, expecco will attach to the main process of the specified executable. Be careful as this is not necessarily the process
drawing the GUI! Use the process id if an application spawns more than one process and you need to make sure you connect to the GUI process and not some background process.
All connection blocks also require you to specify a '''name''' by which the connection should be known in future.
This is needed for when you automate multiple applications at the same time and need to change
'''connection contexts''' during test execution.
Please note that the application to connect to has to be started before the corresponding connection block is executed.
You can change in context of which connection a block is executed with the '''Set Active Connection''' block.
This allows you, for example, to automate and compare the state of applications running on multiple systems in one test case.

=== Establishing a Local Connection ===
If you want to automate an application running on the same host as expecco, there is no need to set up anything! Just use the '''Create Local Connection''' with the mentioned above parameters.

=== Establishing a Remote Connection ===
Make sure that the DotNet Bridge server is started as explained in [[#Preparing a remote system for test exeuction]]
When the bridge is running, you can connect to it with the '''Create Remote Connection''' block using the hostname and IP-Address you specified when you started the bridge.

=== Closing a Connection ===
Remember to always close a connection when it is no longer needed, as it otherwise needlessly consumes resources.
One simple way to do this is to setup your connections in the '''Before Execution''' part of the test suite
and put the '''Close All Connections''' block in the '''After exeuction''' part.

 
== Accessing GUI Elements ==
[[Bild:WindowsAutomation_Library_AccessBlocks.PNG|frame|The Library's GUI Element Access Blocks.]]
[[Bild:WindowsAutomation_Library_AccessBlocksExamples.PNG|frame|A Few Examples on How to Access Elements in Notepad.]]
[[Bild:WindowsAutomation_Library_AccessBlocksModes.PNG|frame|Different Ways to Reference a GUI Element.]]
All Windows applications are built as a ''' tree''' of ''' GUI elements''' .
Some elements act as container of other element - their children. Tables, for example, are containers
for their cell elements which themselves might contain text labels.
At the root of the tree are one or more '''windows''' . When you connect to an application, you get access to
all windows at the tree's root.
To manipulate any of the system under test's GUI element, you first have to gain access to it.
The group '''GUI Element Access''' provides blocks that help you to gain access to the elements. There are 12 blocks in total, divided between ''' Access By XPath''' , '''Access By Property''',
and '''Existence Test'''. For each category, blocks with the same interface exist. The only difference is the method of retrival.

;Get GUI Element : returns a '''single''' GUI Element matching the search condition. If multiple match the condition, an '''arbitrary''' element matching the condition is returned.
:If you want to make sure that there is only one element matching, set '''ensureExclusive''' to true. You can also enforce this globally by setting the environment variable '''ensureExclusive''' in your environment.
:If ensureExclusive is set and more than one element is found, the block will fail and notify you of the ambiguity. This is disabled by default as checking for uniqueness is a very costly operation.
:You can also specify a '''timeout''' after which the search is aborted. This is useful if you know an element should be there soon but might currently be loading.

;Get GUI Elements: returns '''all''' GUI Element matching the search condition. If no element is found, it returns an empty list Timeout and cacheXPath are also applicable.

;Exists: Works exactly the same as '''Get GUI Element''' but does not fail if no element can be found. Additionally provides an output pin specifying if an element has been found.

Both of these blocks are also available in the '''Relative To Anchor''' variety. Those blocks also take a GUI Element as '''anchor''' in relation to which they search.

=== Using XPaths ===

'''XPath''' is the query language this plugin uses for selecting GUI elements in the application's element tree.
You can find the XPath of an element with the [[Expecco GUI Tests Extension Reference|Gui Browser]] or with third-party applications like Inspect.exe [https://msdn.microsoft.com/en-us/library/dd318521(v=vs.85).aspx] or FlaUInspect [https://github.com/FlauTech/FlaUInspect].
An '''XPath''' for the scroll button on the
vertical scrollbar in the german Windows Notepad application looks like this:

<code>/Window[@Name='Unbenannt - Editor']/Document[@Name='Text-Editor']/ScrollBar[@Name='Vertikale Bildlaufleiste']/Button[@Name='Bildlauf nach unten'] </code>

For each level in the GUI tree, a new Location Step containing the child elements Control Type has to be added.
You do not have to use any predicates, the following XPath is valid as well:

<code>/Window/Document/ScrollBar/Button </code>

but might lead to issues as there might be multiple GUI Elements matching this path.
You can select by three predicates that can be mixed and matched in the same query:

; Name: the name the application developer has given an element. Be careful as this name might change during programm execution (See for example Notepad's window name which always begins with the name of the currently opened file.
: <code>/Window[@Name='Unbenannt - Editor'] </code>

; AutomationId: An ID the application developer has given an element. It is meant to be unique between siblings but that is not enforced.
: Many developersleave the ID empty or reuse it, making it useless. You should nontheless use this ID wherever applicable as it is static
: and meant for this exact purpose.
: <code>/Window/Document[@AutomationId='15'] </code>

;List Index: If there are multiple siblings with the same Control Type, you can select one of them by (1-based) list index.
: <code>/Window[1]/Document[1] </code>
: <code>/Window[1]/Document[last()] </code>

'''Please Note''': You can '''only''' use the three predicates above in your XPaths. Other predicates '''DO NOT''' work! If you want to search
an element by another property (e.g. its help text), use the '''By Property''' variant of the block instead. If the property is not unique,
you can select a unique ancestor of the target by property or XPath relative to which the property is unique.
You can then use that ancestor as anchor in the '''Get GUI Element By Property (Relative to Anchor)''' block.

=== Using Wildcards in XPaths ===

XPath also supports '''wildcards'''. You can:
* replace '''one tree level''' with a "*" wildcard:
<code>/Window/Document[@AutomationId='15']/*/Button[1]</code> 
<code>/*/*/*/Button[1] </code>

* replace a '''control type''' with a "*" wildcard:
<code>/Window/*[@AutomationId='15'] </code>

* replace '''an arbitrary amount of tree levels''' with a "//" wildcard:
<code>//Button </code> 
<code>/Window//Button[1] </code>

Especially the last option is useful as it makes your tests more readable as the reader can easily focus on the relevant parts of the xpath.
But be careful. Using wildcards comes at a steep performance cost. If your tests run unacceptably slow, first try to '''remove wildcards where they are not needed'''.

=== Using Properties===

You can also search for elements by property by specifying a value an element's property with the given name must have. For a list of properties a GUI element might have, take a look at Microsoft's documentation [https://docs.microsoft.com/en-us/dotnet/framework/ui-automation/ui-automation-control-patterns-overview#control-pattern-classes-and-interfaces]. It specifies the supported properties for each pattern an element can support.

=== XPath Resolution in Action Blocks ===

Getting a reference to the GUI Element everytime you need to manipulate it in any way can make for very unclean looking test suites as two blocks are needed to perform any action - one for getting a reference to the element and another one for perform the action. The library therefore also allows you to directly feed an xpath into every block that would take a reference to a GUI Element.

The image on the right shows this mode in action. Variants 1 and 2 are functionally equivalent.
While Variant 2 is more concise, Variant 1 is the right choice in most cases. While it has an additional block, you have control over the other input parameters.
You also can recycle the GUI element reference as seen in 3). This is invaluable as the XPath only has to be resolved once. This speeds up test execution by a lot as XPath resolution is very expensive operation.

'''Rule of thumb''': Always use Variant 1 except if you need the reference to the GUI element only once.

 
== Interacting with GUI Elements ==
Once you retrieved a GUI element, you can interact with it by making use of the library's blocks located in the groups '''Elements''', '''Patterns''', and '''Properties'''.
Blocks in those categories take a GUI Element (and sometimes additional data) as input and manipulate it or query for its properties in some way.

[[Bild:WindowsAutomation_Library_ElementsPatternsProperties.png|frame|The Library's Blocks for Interacting With Elements.]]

=== The 'Elements' Group ===

This group contains blocks that are applicable to blocks that only work on '''GUI elements of a specific type'''. For a block's detailed description with examples ,
take a look at the block's documentation in expecco.

Even though not only Checkboxes can be 'checked', the '''Check''' block in the '''Checkbox group''' only works for checkboxes and not e.g. for radio buttons.
Because of this limitation there are not that many blocks targeting specific elements. Most blocks target a specific '''pattern''' instead and are therefore in the '''Patterns''' group.

=== The 'Patterns' Group ===

This group contains blocks that are applicable to GUI elements supporting a certain '''pattern'''. '''Patterns''' describe how a GUI element '''behaves''' rather than what it '''is'''. An element can also support multiple patterns
at the same time. You can find out which patterns an element supports with the '''Get Supported Patterns''' block or by taking a look at Microsoft's documentation about patterns [https://docs.microsoft.com/en-us/dotnet/framework/ui-automation/ui-automation-control-patterns-overview].

Pattern blocks can therefore be '''re-used''' between GUI elements of different types. The '''Expand''' block of the '''ExpandCollapse pattern''', for example, can be used to expand Comboboxes, Menus, Submenus, or Trees.

=== The 'Properties' Group ===

Blocks in the '''Patterns''' and '''Elements''' group already allow you to query the value of properties pertaining to that element or pattern. Blocks of the '''Properties''' group allow you to query properties all elements share as well as arbitrary properties. If you try to retrieve a property an element does not support, the block will fail.

Please note that the '''Get Arbitrary Property''' block can only query for properties that belong to a pattern. You cannot, for example, query "Text" from a textfield as this is not a property, use "Value" of the value pattern instead. Microsoft's documentation has a list of patterns and the properties they provide [https://docs.microsoft.com/en-us/dotnet/framework/ui-automation/ui-automation-control-patterns-overview#control-pattern-classes-and-interfaces]

 
== Automating Keyboard and Mouse ==
[[Bild:WindowsAutomation_Library_KeyboardMouse.png|frame|The Library's Blocks for Interacting With Keyboard and Mouse.]]

You can control keyboard and mouse with the blocks in the groups '''Keyboard''' and '''Mouse''' that can be seen on the right. In contrast to the blocks above which work in context of a GUI element, the keyboard and mouse blocks work on a global level. You therefore do not need to provide a GUI element when using them.

You might want to execute some blocks in context of a GUI elemenet nontheless (e.g. enter a number into a text field instead of just pressing keys while the application is running). You can achieve this by selecting the element with the mouse beforehand as you would do when using the application normally (use the '''Left/Double/Right Click On Element''' blocks for this).
If you do not want to wait for the mouse to move, you can also use the '''Set Focus''' block instead.

=== Keyboard ===
The plugin provides blocks interacting with the keyboard on different abstraction levels. The most versatile block is '''Type With Control Keys Pressed''' where you can specify a string of characters to be typed while any number of control keys (e.g. esc, alt, shift, ctrl, ...) are held down. All other blocks are specializations of this block.

'''Press Control Keys''' e.g. allows you to enter key commands such as renaming files (ALT+F2), starting the task manager (CTRL+ALT+DEL), or closing a window (ALT+F4). '''Press Control Key''' makes it easy to just press a single key (e.g. RETURN to start a new line in an edit box). The '''Shortcuts''' group provides an assorted collection of often used key combinations for your convenience.

Use the '''Type''' to just type some text or, if you just need some throwaway demo text, use '''Type Random Phrase'''.

If you need more fine grained control over the keyboard, you can make use of '''Scan Codes'''. The keyboard sends a scan codeto the operating system whenever a key is pressed or released.
Microsoft provides a list of the scan codes it supports [https://docs.microsoft.com/en-us/previous-versions/visualstudio/visual-studio-6.0/aa299374(v=vs.60)].
'''Press Key By Scan Code''' sends Windows a signal that a key with a given scan code has been pressed (and is held down). The matching '''Release Key By Scan Code''' sends Windows the adverse signal.
Please note that a key that is pressed, stays pressed until it is explicitly released. If you want to just press and release a key by scan code, use '''Type Key By Scan Code'''.

=== Mouse ===
The plugin provides blocks manipulating the mouse in three ways: '''Clicking''', '''Moving''', and interacting with its '''Buttons'''.

 
== Recording and Taking Screenshots ==

= Frequently Asked Questions =

== What is the difference between Click/Invoke/Select/Toggle? ==

== My element supports a certain pattern but blocks of that pattern don't work? ==

== I have designed custom elements, how can I automate them? ==

== I have extended my GUI elements to have custom properties, how can I query them? ==

WindowsAutomation Reference 2.0

2018-05-30T14:09:57Z

Lv:

This is the documentation for the Windows Automation 2.0 plugin.

It provides facilities to automate tests incorporating applications with a GUI based on Windows Presentation Foundation (WPF), WinForms, and the old Win32 API.

=Features=
*Automated GUI testing of WPF, WinForms, and Win32 applications.
*Contains an expecco block library and tools which help to model tests and inspect the GUI of the application.
*Parallel remote test-execution on multiple systems.
*Performs tests against already built executables. No source code changes / recompilation of the application is required.
*Access to GUI components using XPath locators.
*Access objects of the application live at execution time.
*Full access to keyboard and mouse of the target system.
*Lots of additional features such as screen capturing, taking screenshots, highlighting GUI elements, mouse tracking, ...

=Installation and Connection=
The WindowsAutomation testing plugin uses the expecoo ".NET-Bridge" which consists of two parts: A plugin for expecco, and a server executable using the .NET framework running on the remote computer to connect to.

==Requirements==
On the machine running the system under test:
*.NET Framework 4.6.2 [https://www.microsoft.com/net/download/all] or higher.
* One of the following operation systems:
::- Windows 7 SP1
::- Windows 8
::- Windows 8.1
::- Windows 10

::- Windows Server 2008 R2 SP1
::- Windows Server 2012
::- Windows Server 2012 R2
::- Windows Server 2016
::- Windows Server, version 1709

==Plugin Components==
The plugin consists of the following parts:
* The GUI Browser, used to interactively explore your application.
* The Windows Automation Library, which provides blocks that you can use in your test cases.
* The .NET-Bridge server, which provides an interface between the application under test and your tests running in expecco.

==Installing and Configuring the Plugin in Expecco==
The plugin is usually installed automatically by the installer; either included in the main expecco installation or provided as a separate installable add-on package. Its files are stored in the "plugin" subfolder of the expecco installation folder. You can also copy those files manually to that folder, if required. Expecco detects the plugin automatically during startup. You might need to restart your expecco session.

==Preparing a local system for test execution==
If you want to automate an application running on the same host as expecco, there is no need to set up anything! Everything should work out of the box.

TODO: Is that still true with the gui browser?
TODO: Pictures for the connection process

==Preparing a remote system for test exeuction==
The remote system will have to run the ".Net-Bridge server" which in turn connects to expecco.
You just need to copy "DotNetBridgeServer.exe" to the computer your system under test is running on. No further installation is needed.

To start the bridge, navigate to the executable in a shell and start it with the following arguments:
{| class="wikitable"
|-
! Arguments !! Required !! Description
|-
| -s || Yes || Tells the executable to run in server mode (as opposed to client mode).
|-
| -k || Yes || Tells the client to keep the connection open after aconnection has been terminated saving you the hassle to restart it every time a test finishes.
|-
| -a <ip/hostname>|| Yes || The IP-Address of the PC your application is running on.
|-
| -p <int> || No || The port the server should listen on (default is 34318).
|}

=Settings=
TODO: What settings does the plugin have?

=GUI Browser=
The GUI browser allows you to explore a running application. You can browse the application, inspect element properties and execute actions. For a more detailed description also see [[Expecco GUI Tests Extension Reference|Gui Browser]].

=Library=
This article gives a short overview over the design philosophy of the library. You can find more detailed documentation and examples attached to the blocks itself.

== Connecting to an Application ==
To automate an application, you first have to connect to it. You can do this with the
blocks from the '''Connecting''' group.
[[Bild:WindowsAutomation2_Library_ConnectingBlocks.PNG|frame|The Library's Connection Blocks.]]

You can connect to an application by its '''executable name''', or by its '''process id'''.
If you use the executable name, expecco will attach to the main process of the specified executable. Be careful as this is not necessarily the process
drawing the GUI! Use the process id if an application spawns more than one process and you need to make sure you connect to the GUI process and not some background process.
All connection blocks also require you to specify a '''name''' by which the connection should be known in future.
This is needed for when you automate multiple applications at the same time and need to change
'''connection contexts''' during test execution.
Please note that the application to connect to has to be started before the corresponding connection block is executed.
You can change in context of which connection a block is executed with the '''Set Active Connection''' block.
This allows you, for example, to automate and compare the state of applications running on multiple systems in one test case.

=== Establishing a Local Connection ===
If you want to automate an application running on the same host as expecco, there is no need to set up anything! Just use the '''Create Local Connection''' with the mentioned above parameters.

=== Establishing a Remote Connection ===
Make sure that the DotNet Bridge server is started as explained in [[#Preparing a remote system for test exeuction]]
When the bridge is running, you can connect to it with the '''Create Remote Connection''' block using the hostname and IP-Address you specified when you started the bridge.

=== Closing a Connection ===
Remember to always close a connection when it is no longer needed, as it otherwise needlessly consumes resources.
One simple way to do this is to setup your connections in the '''Before Execution''' part of the test suite
and put the '''Close All Connections''' block in the '''After exeuction''' part.

 
== Accessing GUI Elements ==
[[Bild:WindowsAutomation_Library_AccessBlocks.PNG|frame|The Library's GUI Element Access Blocks.]]
[[Bild:WindowsAutomation_Library_AccessBlocksExamples.PNG|frame|A Few Examples on How to Access Elements in Notepad.]]
[[Bild:WindowsAutomation_Library_AccessBlocksModes.PNG|frame|Different Ways to Reference a GUI Element.]]
All Windows applications are built as a ''' tree''' of ''' GUI elements''' .
Some elements act as container of other element - their children. Tables, for example, are containers
for their cell elements which themselves might contain text labels.
At the root of the tree are one or more '''windows''' . When you connect to an application, you get access to
all windows at the tree's root.
To manipulate any of the system under test's GUI element, you first have to gain access to it.
The group '''GUI Element Access''' provides blocks that help you to gain access to the elements. There are 12 blocks in total, divided between ''' Access By XPath''' , '''Access By Property''',
and '''Existence Test'''. For each category, blocks with the same interface exist. The only difference is the method of retrival.

;Get GUI Element : returns a '''single''' GUI Element matching the search condition. If multiple match the condition, an '''arbitrary''' element matching the condition is returned.
:If you want to make sure that there is only one element matching, set '''ensureExclusive''' to true. You can also enforce this globally by setting the environment variable '''ensureExclusive''' in your environment.
:If ensureExclusive is set and more than one element is found, the block will fail and notify you of the ambiguity. This is disabled by default as checking for uniqueness is a very costly operation.
:You can also specify a '''timeout''' after which the search is aborted. This is useful if you know an element should be there soon but might currently be loading.

;Get GUI Elements: returns '''all''' GUI Element matching the search condition. If no element is found, it returns an empty list Timeout and cacheXPath are also applicable.

;Exists: Works exactly the same as '''Get GUI Element''' but does not fail if no element can be found. Additionally provides an output pin specifying if an element has been found.

Both of these blocks are also available in the '''Relative To Anchor''' variety. Those blocks also take a GUI Element as '''anchor''' in relation to which they search.

=== Using XPaths ===

'''XPath''' is the query language this plugin uses for selecting GUI elements in the application's element tree.
You can find the XPath of an element with the [[Expecco GUI Tests Extension Reference|Gui Browser]] or with third-party applications like Inspect.exe [https://msdn.microsoft.com/en-us/library/dd318521(v=vs.85).aspx] or FlaUInspect [https://github.com/FlauTech/FlaUInspect].
An '''XPath''' for the scroll button on the
vertical scrollbar in the german Windows Notepad application looks like this:

<code>/Window[@Name='Unbenannt - Editor']/Document[@Name='Text-Editor']/ScrollBar[@Name='Vertikale Bildlaufleiste']/Button[@Name='Bildlauf nach unten'] </code>

For each level in the GUI tree, a new Location Step containing the child elements Control Type has to be added.
You do not have to use any predicates, the following XPath is valid as well:

<code>/Window/Document/ScrollBar/Button </code>

but might lead to issues as there might be multiple GUI Elements matching this path.
You can select by three predicates that can be mixed and matched in the same query:

; Name: the name the application developer has given an element. Be careful as this name might change during programm execution (See for example Notepad's window name which always begins with the name of the currently opened file.
: <code>/Window[@Name='Unbenannt - Editor'] </code>

; AutomationId: An ID the application developer has given an element. It is meant to be unique between siblings but that is not enforced.
: Many developersleave the ID empty or reuse it, making it useless. You should nontheless use this ID wherever applicable as it is static
: and meant for this exact purpose.
: <code>/Window/Document[@AutomationId='15'] </code>

;List Index: If there are multiple siblings with the same Control Type, you can select one of them by (1-based) list index.
: <code>/Window[1]/Document[1] </code>
: <code>/Window[1]/Document[last()] </code>

'''Please Note''': You can '''only''' use the three predicates above in your XPaths. Other predicates '''DO NOT''' work! If you want to search
an element by another property (e.g. its help text), use the '''By Property''' variant of the block instead. If the property is not unique,
you can select a unique ancestor of the target by property or XPath relative to which the property is unique.
You can then use that ancestor as anchor in the '''Get GUI Element By Property (Relative to Anchor)''' block.

=== Using Wildcards in XPaths ===

XPath also supports '''wildcards'''. You can:
* replace '''one tree level''' with a "*" wildcard:
<code>/Window/Document[@AutomationId='15']/*/Button[1]</code> 
<code>/*/*/*/Button[1] </code>

* replace a '''control type''' with a "*" wildcard:
<code>/Window/*[@AutomationId='15'] </code>

* replace '''an arbitrary amount of tree levels''' with a "//" wildcard:
<code>//Button </code> 
<code>/Window//Button[1] </code>

Especially the last option is useful as it makes your tests more readable as the reader can easily focus on the relevant parts of the xpath.
But be careful. Using wildcards comes at a steep performance cost. If your tests run unacceptably slow, first try to '''remove wildcards where they are not needed'''.

=== Using Properties===

You can also search for elements by property by specifying a value an element's property with the given name must have. For a list of properties a GUI element might have, take a look at Microsoft's documentation [https://docs.microsoft.com/en-us/dotnet/framework/ui-automation/ui-automation-control-patterns-overview#control-pattern-classes-and-interfaces]. It specifies the supported properties for each pattern an element can support.

=== XPath Resolution in Action Blocks ===

Getting a reference to the GUI Element everytime you need to manipulate it in any way can make for very unclean looking test suites as two blocks are needed to perform any action - one for getting a reference to the element and another one for perform the action. The library therefore also allows you to directly feed an xpath into every block that would take a reference to a GUI Element.

The image on the right shows this mode in action. Variants 1 and 2 are functionally equivalent.
While Variant 2 is more concise, Variant 1 is the right choice in most cases. While it has an additional block, you have control over the other input parameters.
You also can recycle the GUI element reference as seen in 3). This is invaluable as the XPath only has to be resolved once. This speeds up test execution by a lot as XPath resolution is very expensive operation.

'''Rule of thumb''': Always use Variant 1 except if you need the reference to the GUI element only once.

 
== Interacting with GUI Elements ==
Once you retrieved a GUI element, you can interact with it by making use of the library's blocks located in the groups '''Elements''', '''Patterns''', and '''Properties'''.
Blocks in those categories take a GUI Element (and sometimes additional data) as input and manipulate it or query for its properties in some way.

[[Bild:WindowsAutomation_Library_ElementsPatternsProperties.png|frame|The Library's Blocks for Interacting With Elements.]]

=== The 'Elements' Group ===

This group contains blocks that are applicable to blocks that only work on '''GUI elements of a specific type'''. For a block's detailed description with examples ,
take a look at the block's documentation in expecco.

Even though not only Checkboxes can be 'checked', the '''Check''' block in the '''Checkbox group''' only works for checkboxes and not e.g. for radio buttons.
Because of this limitation there are not that many blocks targeting specific elements. Most blocks target a specific '''pattern''' instead and are therefore in the '''Patterns''' group.

=== The 'Patterns' Group ===

This group contains blocks that are applicable to GUI elements supporting a certain '''pattern'''. '''Patterns''' describe how a GUI element '''behaves''' rather than what it '''is'''. An element can also support multiple patterns
at the same time. You can find out which patterns an element supports with the '''Get Supported Patterns''' block or by taking a look at Microsoft's documentation about patterns [https://docs.microsoft.com/en-us/dotnet/framework/ui-automation/ui-automation-control-patterns-overview].

Pattern blocks can therefore be '''re-used''' between GUI elements of different types. The '''Expand''' block of the '''ExpandCollapse pattern''', for example, can be used to expand Comboboxes, Menus, Submenus, or Trees.

=== The 'Properties' Group ===

Blocks in the '''Patterns''' and '''Elements''' group already allow you to query the value of properties pertaining to that element or pattern. Blocks of the '''Properties''' group allow you to query properties all elements share as well as arbitrary properties. If you try to retrieve a property an element does not support, the block will fail.

Please note that the '''Get Arbitrary Property''' block can only query for properties that belong to a pattern. You cannot, for example, query "Text" from a textfield as this is not a property, use "Value" of the value pattern instead. Microsoft's documentation has a list of patterns and the properties they provide [https://docs.microsoft.com/en-us/dotnet/framework/ui-automation/ui-automation-control-patterns-overview#control-pattern-classes-and-interfaces]

 
== Automating Keyboard and Mouse ==
[[Bild:WindowsAutomation_Library_KeyboardMouse.png|frame|The Library's Blocks for Interacting With Keyboard and Mouse.]]

You can control keyboard and mouse with the blocks in the groups '''Keyboard''' and '''Mouse''' that can be seen on the right. In contrast to the blocks above which work in context of a GUI element, the keyboard and mouse blocks work on a global level. You therefore do not need to provide a GUI element when using them.

You might want to execute some blocks in context of a GUI elemenet nontheless (e.g. enter a number into a text field instead of just pressing keys while the application is running). You can achieve this by selecting the element with the mouse beforehand as you would do when using the application normally (use the '''Left/Double/Right Click On Element''' blocks for this).
If you do not want to wait for the mouse to move, you can also use the '''Set Focus''' block instead.

=== Keyboard ===
The plugin provides blocks interacting with the keyboard on different abstraction levels. The most versatile block is '''Type With Control Keys Pressed''' where you can specify a string of characters to be typed while any number of control keys (e.g. esc, alt, shift, ctrl, ...) are held down. All other blocks are specializations of this block.

'''Press Control Keys''' e.g. allows you to enter key commands such as renaming files (ALT+F2), starting the task manager (CTRL+ALT+DEL), or closing a window (ALT+F4). '''Press Control Key''' makes it easy to just press a single key (e.g. RETURN to start a new line in an edit box). The '''Shortcuts''' group provides an assorted collection of often used key combinations for your convenience.

Use the '''Type''' to just type some text or, if you just need some throwaway demo text, use '''Type Random Phrase'''.

If you need more fine grained control over the keyboard, you can make use of '''Scan Codes'''. The keyboard sends a scan codeto the operating system whenever a key is pressed or released.
Microsoft provides a list of the scan codes it supports [https://docs.microsoft.com/en-us/previous-versions/visualstudio/visual-studio-6.0/aa299374(v=vs.60)].
'''Press Key By Scan Code''' sends Windows a signal that a key with a given scan code has been pressed (and is hold down). The matching '''Release Key By Scan Code''' sends Windows the adverse signal.
Please note that a key that is pressed, stays pressed until it is explicitly released. If you want to just press and release a key by scan code, use '''Type Key By Scan Code'''.

=== Mouse ===
The plugin provides blocks manipulating the mouse in three ways: '''Clicking''', '''Moving''', and interacting with its '''Buttons'''.

 
== Recording and Taking Screenshots ==

= Frequently Asked Questions =

== What is the difference between Click/Invoke/Select/Toggle? ==

== My element supports a certain pattern but blocks of that pattern don't work? ==

== I have designed custom elements, how can I automate them? ==

== I have extended my GUI elements to have custom properties, how can I query them? ==

WindowsAutomation Reference 2.0

2018-05-30T12:07:08Z

Lv:

This is the documentation for the Windows Automation 2.0 plugin.

It provides facilities to automate tests incorporating applications with a GUI based on Windows Presentation Foundation (WPF), WinForms, and the old Win32 API.

=Features=
*Automated GUI testing of WPF, WinForms, and Win32 applications.
*Contains an expecco block library and tools which help to model tests and inspect the GUI of the application.
*Parallel remote test-execution on multiple systems.
*Performs tests against already built executables. No source code changes / recompilation of the application is required.
*Access to GUI components using XPath locators.
*Access objects of the application live at execution time.
*Full access to keyboard and mouse of the target system.
*Lots of additional features such as screen capturing, taking screenshots, highlighting GUI elements, mouse tracking, ...

=Installation and Connection=
The WindowsAutomation testing plugin uses the expecoo ".NET-Bridge" which consists of two parts: A plugin for expecco, and a server executable using the .NET framework running on the remote computer to connect to.

==Requirements==
On the machine running the system under test:
*.NET Framework 4.6.2 [https://www.microsoft.com/net/download/all] or higher.
* One of the following operation systems:
::- Windows 7 SP1
::- Windows 8
::- Windows 8.1
::- Windows 10

::- Windows Server 2008 R2 SP1
::- Windows Server 2012
::- Windows Server 2012 R2
::- Windows Server 2016
::- Windows Server, version 1709

==Plugin Components==
The plugin consists of the following parts:
* The GUI Browser, used to interactively explore your application.
* The Windows Automation Library, which provides blocks that you can use in your test cases.
* The .NET-Bridge server, which provides an interface between the application under test and your tests running in expecco.

==Installing and Configuring the Plugin in Expecco==
The plugin is usually installed automatically by the installer; either included in the main expecco installation or provided as a separate installable add-on package. Its files are stored in the "plugin" subfolder of the expecco installation folder. You can also copy those files manually to that folder, if required. Expecco detects the plugin automatically during startup. You might need to restart your expecco session.

==Preparing a local system for test execution==
If you want to automate an application running on the same host as expecco, there is no need to set up anything! Everything should work out of the box.

TODO: Is that still true with the gui browser?
TODO: Pictures for the connection process

==Preparing a remote system for test exeuction==
The remote system will have to run the ".Net-Bridge server" which in turn connects to expecco.
You just need to copy "DotNetBridgeServer.exe" to the computer your system under test is running on. No further installation is needed.

To start the bridge, navigate to the executable in a shell and start it with the following arguments:
{| class="wikitable"
|-
! Arguments !! Required !! Description
|-
| -s || Yes || Tells the executable to run in server mode (as opposed to client mode).
|-
| -k || Yes || Tells the client to keep the connection open after aconnection has been terminated saving you the hassle to restart it every time a test finishes.
|-
| -a <ip/hostname>|| Yes || The IP-Address of the PC your application is running on.
|-
| -p <int> || No || The port the server should listen on (default is 34318).
|}

=Settings=
TODO: What settings does the plugin have?

=GUI Browser=
The GUI browser allows you to explore a running application. You can browse the application, inspect element properties and execute actions. For a more detailed description also see [[Expecco GUI Tests Extension Reference|Gui Browser]].

=Library=
This article gives a short overview over the design philosophy of the library. You can find more detailed documentation and examples attached to the blocks itself.

== Connecting to an Application ==
To automate an application, you first have to connect to it. You can do this with the
blocks from the '''Connecting''' group.
[[Bild:WindowsAutomation2_Library_ConnectingBlocks.PNG|frame|The Library's Connection Blocks.]]

You can connect to an application by its '''executable name''', or by its '''process id'''.
If you use the executable name, expecco will attach to the main process of the specified executable. Be careful as this is not necessarily the process
drawing the GUI! Use the process id if an application spawns more than one process and you need to make sure you connect to the GUI process and not some background process.
All connection blocks also require you to specify a '''name''' by which the connection should be known in future.
This is needed for when you automate multiple applications at the same time and need to change
'''connection contexts''' during test execution.
Please note that the application to connect to has to be started before the corresponding connection block is executed.
You can change in context of which connection a block is executed with the '''Set Active Connection''' block.
This allows you, for example, to automate and compare the state of applications running on multiple systems in one test case.

=== Establishing a Local Connection ===
If you want to automate an application running on the same host as expecco, there is no need to set up anything! Just use the '''Create Local Connection''' with the mentioned above parameters.

=== Establishing a Remote Connection ===
Make sure that the DotNet Bridge server is started as explained in [[#Preparing a remote system for test exeuction]]
When the bridge is running, you can connect to it with the '''Create Remote Connection''' block using the hostname and IP-Address you specified when you started the bridge.

=== Closing a Connection ===
Remember to always close a connection when it is no longer needed, as it otherwise needlessly consumes resources.
One simple way to do this is to setup your connections in the '''Before Execution''' part of the test suite
and put the '''Close All Connections''' block in the '''After exeuction''' part.

 
== Accessing GUI Elements ==
[[Bild:WindowsAutomation_Library_AccessBlocks.PNG|frame|The Library's GUI Element Access Blocks.]]
[[Bild:WindowsAutomation_Library_AccessBlocksExamples.PNG|frame|A Few Examples on How to Access Elements in Notepad.]]
[[Bild:WindowsAutomation_Library_AccessBlocksModes.PNG|frame|Different Ways to Reference a GUI Element.]]
All Windows applications are built as a ''' tree''' of ''' GUI elements''' .
Some elements act as container of other element - their children. Tables, for example, are containers
for their cell elements which themselves might contain text labels.
At the root of the tree are one or more '''windows''' . When you connect to an application, you get access to
all windows at the tree's root.
To manipulate any of the system under test's GUI element, you first have to gain access to it.
The group '''GUI Element Access''' provides blocks that help you to gain access to the elements. There are 12 blocks in total, divided between ''' Access By XPath''' , '''Access By Property''',
and '''Existence Test'''. For each category, blocks with the same interface exist. The only difference is the method of retrival.

;Get GUI Element : returns a '''single''' GUI Element matching the search condition. If multiple match the condition, an '''arbitrary''' element matching the condition is returned.
:If you want to make sure that there is only one element matching, set '''ensureExclusive''' to true. You can also enforce this globally by setting the environment variable '''ensureExclusive''' in your environment.
:If ensureExclusive is set and more than one element is found, the block will fail and notify you of the ambiguity. This is disabled by default as checking for uniqueness is a very costly operation.
:You can also specify a '''timeout''' after which the search is aborted. This is useful if you know an element should be there soon but might currently be loading.

;Get GUI Elements: returns '''all''' GUI Element matching the search condition. If no element is found, it returns an empty list Timeout and cacheXPath are also applicable.

;Exists: Works exactly the same as '''Get GUI Element''' but does not fail if no element can be found. Additionally provides an output pin specifying if an element has been found.

Both of these blocks are also available in the '''Relative To Anchor''' variety. Those blocks also take a GUI Element as '''anchor''' in relation to which they search.

=== Using XPaths ===

'''XPath''' is the query language this plugin uses for selecting GUI elements in the application's element tree.
You can find the XPath of an element with the [[Expecco GUI Tests Extension Reference|Gui Browser]] or with third-party applications like Inspect.exe [https://msdn.microsoft.com/en-us/library/dd318521(v=vs.85).aspx] or FlaUInspect [https://github.com/FlauTech/FlaUInspect].
An '''XPath''' for the scroll button on the
vertical scrollbar in the german Windows Notepad application looks like this:

<code>/Window[@Name='Unbenannt - Editor']/Document[@Name='Text-Editor']/ScrollBar[@Name='Vertikale Bildlaufleiste']/Button[@Name='Bildlauf nach unten'] </code>

For each level in the GUI tree, a new Location Step containing the child elements Control Type has to be added.
You do not have to use any predicates, the following XPath is valid as well:

<code>/Window/Document/ScrollBar/Button </code>

but might lead to issues as there might be multiple GUI Elements matching this path.
You can select by three predicates that can be mixed and matched in the same query:

; Name: the name the application developer has given an element. Be careful as this name might change during programm execution (See for example Notepad's window name which always begins with the name of the currently opened file.
: <code>/Window[@Name='Unbenannt - Editor'] </code>

; AutomationId: An ID the application developer has given an element. It is meant to be unique between siblings but that is not enforced.
: Many developersleave the ID empty or reuse it, making it useless. You should nontheless use this ID wherever applicable as it is static
: and meant for this exact purpose.
: <code>/Window/Document[@AutomationId='15'] </code>

;List Index: If there are multiple siblings with the same Control Type, you can select one of them by (1-based) list index.
: <code>/Window[1]/Document[1] </code>
: <code>/Window[1]/Document[last()] </code>

'''Please Note''': You can '''only''' use the three predicates above in your XPaths. Other predicates '''DO NOT''' work! If you want to search
an element by another property (e.g. its help text), use the '''By Property''' variant of the block instead. If the property is not unique,
you can select a unique ancestor of the target by property or XPath relative to which the property is unique.
You can then use that ancestor as anchor in the '''Get GUI Element By Property (Relative to Anchor)''' block.

=== Using Wildcards in XPaths ===

XPath also supports '''wildcards'''. You can:
* replace '''one tree level''' with a "*" wildcard:
<code>/Window/Document[@AutomationId='15']/*/Button[1]</code> 
<code>/*/*/*/Button[1] </code>

* replace a '''control type''' with a "*" wildcard:
<code>/Window/*[@AutomationId='15'] </code>

* replace '''an arbitrary amount of tree levels''' with a "//" wildcard:
<code>//Button </code> 
<code>/Window//Button[1] </code>

Especially the last option is useful as it makes your tests more readable as the reader can easily focus on the relevant parts of the xpath.
But be careful. Using wildcards comes at a steep performance cost. If your tests run unacceptably slow, first try to '''remove wildcards where they are not needed'''.

=== Using Properties===

You can also search for elements by property by specifying a value an element's property with the given name must have. For a list of properties a GUI element might have, take a look at Microsoft's documentation [https://docs.microsoft.com/en-us/dotnet/framework/ui-automation/ui-automation-control-patterns-overview#control-pattern-classes-and-interfaces]. It specifies the supported properties for each pattern an element can support.

=== XPath Resolution in Action Blocks ===

Getting a reference to the GUI Element everytime you need to manipulate it in any way can make for very unclean looking test suites as two blocks are needed to perform any action - one for getting a reference to the element and another one for perform the action. The library therefore also allows you to directly feed an xpath into every block that would take a reference to a GUI Element.

The image on the right shows this mode in action. Variants 1 and 2 are functionally equivalent.
While Variant 2 is more concise, Variant 1 is the right choice in most cases. While it has an additional block, you have control over the other input parameters.
You also can recycle the GUI element reference as seen in 3). This is invaluable as the XPath only has to be resolved once. This speeds up test execution by a lot as XPath resolution is very expensive operation.

'''Rule of thumb''': Always use Variant 1 except if you need the reference to the GUI element only once.

 
== Interacting with GUI Elements ==
Once you retrieved a GUI element, you can interact with it by making use of the library's blocks located in the groups '''Elements''', '''Patterns''', and '''Properties'''.
Blocks in those categories take a GUI Element (and sometimes additional data) as input and manipulate it or query for its properties in some way.

[[Bild:WindowsAutomation_Library_ElementsPatternsProperties.png|frame|The Library's Blocks for Interacting With Elements.]]

=== The 'Elements' Group ===

This group contains blocks that are applicable to blocks that only work on '''GUI elements of a specific type'''. For a block's detailed description with examples ,
take a look at the block's documentation in expecco.

Even though not only Checkboxes can be 'checked', the '''Check''' block in the '''Checkbox group''' only works for checkboxes and not e.g. for radio buttons.
Because of this limitation there are not that many blocks targeting specific elements. Most blocks target a specific '''pattern''' instead and are therefore in the '''Patterns''' group.

=== The 'Patterns' Group ===

This group contains blocks that are applicable to GUI elements supporting a certain '''pattern'''. '''Patterns''' describe how a GUI element '''behaves''' rather than what it '''is'''. An element can also support multiple patterns
at the same time. You can find out which patterns an element supports with the '''Get Supported Patterns''' block or by taking a look at Microsoft's documentation about patterns [https://docs.microsoft.com/en-us/dotnet/framework/ui-automation/ui-automation-control-patterns-overview].

Pattern blocks can therefore be '''re-used''' between GUI elements of different types. The '''Expand''' block of the '''ExpandCollapse pattern''', for example, can be used to expand Comboboxes, Menus, Submenus, or Trees.

=== The 'Properties' Group ===

Blocks in the '''Patterns''' and '''Elements''' group already allow you to query the value of properties pertaining to that element or pattern. Blocks of the '''Properties''' group allow you to query properties all elements share as well as arbitrary properties. If you try to retrieve a property an element does not support, the block will fail.

Please note that the '''Get Arbitrary Property''' block can only query for properties that belong to a pattern. You cannot, for example, query "Text" from a textfield as this is not a property, use "Value" of the value pattern instead. Microsoft's documentation has a list of patterns and the properties they provide [https://docs.microsoft.com/en-us/dotnet/framework/ui-automation/ui-automation-control-patterns-overview#control-pattern-classes-and-interfaces]

 
== Automating Keyboard and Mouse ==
[[Bild:WindowsAutomation_Library_KeyboardMouse.png|frame|The Library's Blocks for Interacting With Keyboard and Mouse.]]

You can control keyboard and mouse with the blocks in the groups '''Keyboard''' and '''Mouse''' that can be seen on the right. In contrast to the blocks above which work in context of a GUI element, the keyboard and mouse blocks work on a global level. You therefore do not need to provide a GUI element when using them.

You might want to execute some blocks in context of a GUI elemenet nontheless (e.g. enter a number into a text field instead of just pressing keys while the application is running). You can achieve this by selecting the element with the mouse beforehand as you would do when using the application normally (use the '''Left/Double/Right Click On Element''' blocks for this).
If you do not want to wait for the mouse to move, you can also use the '''Set Focus''' block instead.

===

= Frequently Asked Questions =

== What is the difference between Click/Invoke/Select/Toggle? ==

== My element supports a certain pattern but blocks of that pattern don't work? ==

== I have designed custom elements, how can I automate them? ==

== I have extended my GUI elements to have custom properties, how can I query them? ==

Datei:WindowsAutomation Library KeyboardMouse.png

2018-05-30T11:43:36Z

Lv:

WindowsAutomation Reference 2.0

2018-05-30T09:09:21Z

Lv:

This is the documentation for the Windows Automation 2.0 plugin.

It provides facilities to automate tests incorporating applications with a GUI based on Windows Presentation Foundation (WPF), WinForms, and the old Win32 API.

=Features=
*Automated GUI testing of WPF, WinForms, and Win32 applications.
*Contains an expecco block library and tools which help to model tests and inspect the GUI of the application.
*Parallel remote test-execution on multiple systems.
*Performs tests against already built executables. No source code changes / recompilation of the application is required.
*Access to GUI components using XPath locators.
*Access objects of the application live at execution time.
*Full access to keyboard and mouse of the target system.
*Lots of additional features such as screen capturing, taking screenshots, highlighting GUI elements, mouse tracking, ...

=Installation and Connection=
The WindowsAutomation testing plugin uses the expecoo ".NET-Bridge" which consists of two parts: A plugin for expecco, and a server executable using the .NET framework running on the remote computer to connect to.

==Requirements==
On the machine running the system under test:
*.NET Framework 4.6.2 [https://www.microsoft.com/net/download/all] or higher.
* One of the following operation systems:
::- Windows 7 SP1
::- Windows 8
::- Windows 8.1
::- Windows 10

::- Windows Server 2008 R2 SP1
::- Windows Server 2012
::- Windows Server 2012 R2
::- Windows Server 2016
::- Windows Server, version 1709

==Plugin Components==
The plugin consists of the following parts:
* The GUI Browser, used to interactively explore your application.
* The Windows Automation Library, which provides blocks that you can use in your test cases.
* The .NET-Bridge server, which provides an interface between the application under test and your tests running in expecco.

==Installing and Configuring the Plugin in Expecco==
The plugin is usually installed automatically by the installer; either included in the main expecco installation or provided as a separate installable add-on package. Its files are stored in the "plugin" subfolder of the expecco installation folder. You can also copy those files manually to that folder, if required. Expecco detects the plugin automatically during startup. You might need to restart your expecco session.

==Preparing a local system for test execution==
If you want to automate an application running on the same host as expecco, there is no need to set up anything! Everything should work out of the box.

TODO: Is that still true with the gui browser?
TODO: Pictures for the connection process

==Preparing a remote system for test exeuction==
The remote system will have to run the ".Net-Bridge server" which in turn connects to expecco.
You just need to copy "DotNetBridgeServer.exe" to the computer your system under test is running on. No further installation is needed.

To start the bridge, navigate to the executable in a shell and start it with the following arguments:
{| class="wikitable"
|-
! Arguments !! Required !! Description
|-
| -s || Yes || Tells the executable to run in server mode (as opposed to client mode).
|-
| -k || Yes || Tells the client to keep the connection open after aconnection has been terminated saving you the hassle to restart it every time a test finishes.
|-
| -a <ip/hostname>|| Yes || The IP-Address of the PC your application is running on.
|-
| -p <int> || No || The port the server should listen on (default is 34318).
|}

=Settings=
TODO: What settings does the plugin have?

=GUI Browser=
The GUI browser allows you to explore a running application. You can browse the application, inspect element properties and execute actions. For a more detailed description also see [[Expecco GUI Tests Extension Reference|Gui Browser]].

=Library=
This article gives a short overview over the design philosophy of the library. You can find more detailed documentation and examples attached to the blocks itself.

== Connecting to an Application ==
To automate an application, you first have to connect to it. You can do this with the
blocks from the '''Connecting''' group.
[[Bild:WindowsAutomation2_Library_ConnectingBlocks.PNG|frame|The Library's Connection Blocks.]]

You can connect to an application by its '''executable name''', or by its '''process id'''.
If you use the executable name, expecco will attach to the main process of the specified executable. Be careful as this is not necessarily the process
drawing the GUI! Use the process id if an application spawns more than one process and you need to make sure you connect to the GUI process and not some background process.
All connection blocks also require you to specify a '''name''' by which the connection should be known in future.
This is needed for when you automate multiple applications at the same time and need to change
'''connection contexts''' during test execution.
Please note that the application to connect to has to be started before the corresponding connection block is executed.
You can change in context of which connection a block is executed with the '''Set Active Connection''' block.
This allows you, for example, to automate and compare the state of applications running on multiple systems in one test case.

=== Establishing a Local Connection ===
If you want to automate an application running on the same host as expecco, there is no need to set up anything! Just use the '''Create Local Connection''' with the mentioned above parameters.

=== Establishing a Remote Connection ===
Make sure that the DotNet Bridge server is started as explained in [[#Preparing a remote system for test exeuction]]
When the bridge is running, you can connect to it with the '''Create Remote Connection''' block using the hostname and IP-Address you specified when you started the bridge.

=== Closing a Connection ===
Remember to always close a connection when it is no longer needed, as it otherwise needlessly consumes resources.
One simple way to do this is to setup your connections in the '''Before Execution''' part of the test suite
and put the '''Close All Connections''' block in the '''After exeuction''' part.

 
== Accessing GUI Elements ==
[[Bild:WindowsAutomation_Library_AccessBlocks.PNG|frame|The Library's GUI Element Access Blocks.]]
[[Bild:WindowsAutomation_Library_AccessBlocksExamples.PNG|frame|A Few Examples on How to Access Elements in Notepad.]]
All Windows applications are built as a ''' tree''' of ''' GUI elements''' .
Some elements act as container of other element - their children. Tables, for example, are containers
for their cell elements which themselves might contain text labels.
At the root of the tree are one or more '''windows''' . When you connect to an application, you get access to
all windows at the tree's root.
To manipulate any of the system under test's GUI element, you first have to gain access to it.
The group '''GUI Element Access''' provides blocks that help you to gain access to the elements. There are 12 blocks in total, divided between ''' Access By XPath''' , '''Access By Property''',
and '''Existence Test'''. For each category, blocks with the same interface exist. The only difference is the method of retrival.

;Get GUI Element : returns a '''single''' GUI Element matching the search condition. If multiple match the condition, an '''arbitrary''' element matching the condition is returned.
:If you want to make sure that there is only one element matching, set '''ensureExclusive''' to true. You can also enforce this globally by setting the environment variable '''ensureExclusive''' in your environment.
:If ensureExclusive is set and more than one element is found, the block will fail and notify you of the ambiguity. This is disabled by default as checking for uniqueness is a very costly operation.
:You can also specify a '''timeout''' after which the search is aborted. This is useful if you know an element should be there soon but might currently be loading.

;Get GUI Elements: returns '''all''' GUI Element matching the search condition. If no element is found, it returns an empty list Timeout and cacheXPath are also applicable.

;Exists: Works exactly the same as '''Get GUI Element''' but does not fail if no element can be found. Additionally provides an output pin specifying if an element has been found.

Both of these blocks are also available in the '''Relative To Anchor''' variety. Those blocks also take a GUI Element as '''anchor''' in relation to which they search.

=== Using XPaths ===

'''XPath''' is the query language this plugin uses for selecting GUI elements in the application's element tree.
You can find the XPath of an element with the [[Expecco GUI Tests Extension Reference|Gui Browser]] or with third-party applications like Inspect.exe [https://msdn.microsoft.com/en-us/library/dd318521(v=vs.85).aspx] or FlaUInspect [https://github.com/FlauTech/FlaUInspect].
An '''XPath''' for the scroll button on the
vertical scrollbar in the german Windows Notepad application looks like this:

<code>/Window[@Name='Unbenannt - Editor']/Document[@Name='Text-Editor']/ScrollBar[@Name='Vertikale Bildlaufleiste']/Button[@Name='Bildlauf nach unten'] </code>

For each level in the GUI tree, a new Location Step containing the child elements Control Type has to be added.
You do not have to use any predicates, the following XPath is valid as well:

<code>/Window/Document/ScrollBar/Button </code>

but might lead to issues as there might be multiple GUI Elements matching this path.
You can select by three predicates that can be mixed and matched in the same query:

; Name: the name the application developer has given an element. Be careful as this name might change during programm execution (See for example Notepad's window name which always begins with the name of the currently opened file.
: <code>/Window[@Name='Unbenannt - Editor'] </code>

; AutomationId: An ID the application developer has given an element. It is meant to be unique between siblings but that is not enforced.
: Many developersleave the ID empty or reuse it, making it useless. You should nontheless use this ID wherever applicable as it is static
: and meant for this exact purpose.
: <code>/Window/Document[@AutomationId='15'] </code>

;List Index: If there are multiple siblings with the same Control Type, you can select one of them by (1-based) list index.
: <code>/Window[1]/Document[1] </code>
: <code>/Window[1]/Document[last()] </code>

=== Using Wildcards in XPaths ===

XPath also supports '''wildcards'''. You can:
* replace '''one tree level''' with a "*" wildcard:
<code>/Window/Document[@AutomationId='15']/*/Button[1]</code> 
<code>/*/*/*/Button[1] </code>

* replace a '''control type''' with a "*" wildcard:
<code>/Window/*[@AutomationId='15'] </code>

* replace '''an arbitrary amount of tree levels''' with a "//" wildcard:
<code>//Button </code> 
<code>/Window//Button[1] </code>

Especially the last option is useful as it makes your tests more readable as the reader can easily focus on the relevant parts of the xpath.
But be careful. Using wildcards comes at a steep performance cost. If your tests run unacceptably slow, first try to '''remove wildcards where they are not needed'''.

=== Using Properties===

You can also search for elements by property by specifying a value an element's property with the given name must have. For a list of properties a GUI element might have, take a look at Microsoft's documentation [https://docs.microsoft.com/en-us/dotnet/framework/ui-automation/ui-automation-control-patterns-overview#control-pattern-classes-and-interfaces]. It specifies the supported properties for each pattern an element can support.

=== XPath Resolution in Action Blocks ===
[[Bild:WindowsAutomation_Library_AccessBlocksModes.PNG|frame|Different Ways to Reference a GUI Element.]]
Getting a reference to the GUI Element everytime you need to manipulate it in any way can make for very unclean looking test suites as two blocks are needed to perform any action - one for getting a reference to the element and another one for perform the action. The library therefore also allows you to directly feed an xpath into every block that would take a reference to a GUI Element.

The image on the right shows this mode in action. Variants 1 and 2 are functionally equivalent.
While Variant 2 is more concise, Variant 1 is the right choice in most cases. While it has an additional block, you have control over the other input parameters.
You also can recycle the GUI element reference as seen in 3). This is invaluable as the XPath only has to be resolved once. This speeds up test execution by a lot as XPath resolution is very expensive operation.

'''Rule of thumb''': Always use Variant 1 except if you need the reference to the GUI element not more than once during test execution.

 
== Interacting with GUI Elements ==
Once you retrieved a GUI element, you can interact with it by making use of the library's blocks located in the groups '''Elements''', '''Patterns''', and '''Properties'''.
Blocks in those categories take a GUI Element (and sometimes additional data) as input and manipulate it or query for its properties in some way.

[[Bild:WindowsAutomation_Library_ElementsPatternsProperties.png|frame|The Library's Blocks for Interacting With Elements.]]

=== The 'Elements' Group ===

This group contains blocks that are applicable to blocks that only work on '''GUI elements of a specific type'''. For a block's detailed description with examples ,
take a look at the block's documentation in expecco.

Even though not only Checkboxes can be 'checked', the '''Check''' block in the '''Checkbox group''' only works for checkboxes and not e.g. for radio buttons.
Because of this limitation there are not that many blocks targeting specific elements. Most blocks target a specific '''pattern''' instead and are therefore in the '''Patterns''' group.

=== The 'Patterns' Group ===

This group contains blocks that are applicable to GUI elements supporting a certain '''pattern'''.
=== The 'Properties' Group ===

== Automating Keyboard and Mouse ==

= Frequently Asked Questions =

== What is the difference between Click/Invoke/Select/Toggle? ==

Datei:WindowsAutomation Library ElementsPatternsProperties.png

2018-05-30T08:05:20Z

Lv:

Datei:WindowsAutomation Library Elements.PNG

2018-05-30T07:38:40Z

Lv:

Hauptseite/en

2018-05-30T05:24:07Z

Lv: /* GUI Testing */

= expecco =

== Release Notes ==
* [[Release Notes expecco/en|Release Notes expecco]]

== General, Overview, Concepts ==
* [[expecco Overview/en|Overview]]
* [[Concepts/en|Concepts]] - concepts; testplan, testcase, activities, verdicts
* [[Glossary/en|Glossary]]
* [[FAQ/en|FAQ]]

=== Installation, Configuration & Setup ===
* [[Installation/en|Installation]] - initial installation, license files, patches
* [[Configuration & Setup/en|Configuration & Setup]] - JRE/JDK setup, paths
* [[Personal Settings/en|Personal Settings]] - editor settings

=== Command Line and Remote Control Services ===
* [[Command Line Options/en|Command Line Options and RPC Services]]
** [[Command Line Options/en#Command_Line|Command Line]]
** [[Command Line Options/en#Expecco_SOAP_Service_Interface|Remote Control via SOAP]]
** [[Command Line Options/en#Expecco_REST_Service_Interface|Remote Control via REST]]
** [[Command Line Options/en#Scripting|Scripting by File or via Telnet]]

=== Report Generation ===
* [[Report Generation/en|Report Generation]]

== expecco UI ==

* [[General Info on the Expecco UI/en|General Info on the Expecco UI]]
* [[Menu/en|Menu]]
* [[Toolbar/en|Toolbar]]
* [[Navigation Tree/en|Navigation Tree]]
* [[Settings/en|Settings]]
* [[Testsuite Browser/en|Testsuite Browser]]
* [[Expecco Remote Control APP/en|Expecco Remote Control APP]]

==Tree-Elements==

* [[Tree Elements/en|Tree Elements]]
* [[Folder Element/en|Folder Element]]
* [[Datatype Element/en|Datatype Element]]
* [[Testplan Element/en|Testplan Element]]
* [[Block Element/en|Block Element]]
** [[ElementaryBlock Element/en|Elementary Block Element]]
** [[CompoundBlock Element/en|Compound Block Element]]
** [[KeywordBlock Element/en|KeywordBlock Element]]
** [[TestDataGeneratorBlock Element/en|TestDataGeneratorBlock Element]]
** [[VirtualBlock Element/en|Virtual Block Element]]
** [[UnimplementedBlock Element/en|Unimplemented Block Element]]
** [[GUIBlock Element/en|GUIBlock Element]]
* [[Inventory Element/en|Inventory Element]]
* [[Skill Element/en|Skill Element]]
* [[Resource Element/en|Resource Element]]
* [[Attachment Element/en|Attachment Element]]
* [[ReportTemplate Element/en|ReportTemplate Element]]

== Editors ==

* [[Documentation Editor/en|Documentation Editor]]
* [[History Editor/en|History Editor]]
* [[Testsuite Editor/en|Testsuite Editor]]
** [[Testsuite Editor-Environment Editor/en|Testsuite Editor: Environment Editor]]
** [[Testsuite Editor-ExecutionSettings Editor/en|Testsuite Editor: Execution Settings Editor]]
** [[Testsuite Editor-ReportParameter Editor/en|Testsuite Editor: Report Parameter Editor]]
** [[Testsuite Editor-Metadata Editor/en|Testsuite Editor: Metadata Editor]]
** [[Testsuite Editor-StatisticData Editor/en|Testsuite Editor: Statistic Data Editor]]
** [[TestsuiteHistory Editor/en|Testsuite History Editor]]
* [[Block Editor/en|Block Editor]]
** [[Scheme Editor/en|Scheme Editor]]
** [[ElementaryBlock Editor-Code Editor/en|Elementary Block: Code Editor]]
** [[BlockFunctionalityTestEditor/en|Block Functionality Test Editor]]
** [[BlockFunctionalityRunner/en|Block Functionality Runner]]
** [[BlockSkill Editor/en|Block Skill Editor]]
** [[CompoundBlock Editor-CompoundWorksheet Editor/en|Compound Block: Compound Diagram Editor]]
** [[CompoundBlock Editor-Environment Editor/en|Compound Block: Environment Editor]]
** [[KeywordBlock Editor-KeywordActionList Editor/en|Keyword Block: Keyword Action List Editor]]
** [[TestDataGeneratorBlock Editor-TestData Editor/en|TestData Generator Block: TestData Editor]]
** [[TableDrivenBlock Editor-Table Editor/en|Table Driven Block: Table Editor]]
* [[Testplan Editor/en|Testplan Editor]]
** [[Testplan Editor-TestplanEnvironment Editor/en|Testplan Editor: Testplan Environment Editor]]
** [[Testplan Editor-TestplanListView Editor/en|Testplan Editor: Testplan List Editor]]
** [[Testplan Editor-ReportParameter Editor/en|Testplan Editor: Testplan Report Parameter Editor]]
* [[Datatype Editor/en|Datatype Editor]]
* [[Inventory Editor/en|Inventory Editor]]
* [[ReportParameter Editor/en|Report Parameter Editor]]
* [[Resource Editor/en|Resource Editor]]
* [[Skill Editor/en|Skill Editor]]
* [[CategoryContainer Editor/en|Category/Container Editor]]
* [[Documentation Editor/en|Documentation Editor]]
* [[Attachment Editor/en|Attachment Editor]]
** [[FileAttachment Editor/en|File Attachment Editor]]
** [[URLAttachment Editor/en|URL Attachment Editor]]
** [[ReportTemplateAttachment Editor/en|Report Template Editor]]
* [[GUI Editor-GUICode Editor/en|GUI Editor: GUICode Editor]]

==Diagram-Elements==


* [[DiagramElements-Pin/en|Pin]]
** [[DiagramElements-Pin/en#Input Pin|Input Pin]]
*** [[DiagramElements-Pin/en#Enable Input Pin|Enable (Trigger-) Input Pin]]
*** [[DiagramElements-Pin/en#Cancel Input Pin|Cancel Input Pin]]
*** [[DiagramElements-Pin/en#Iterate Input Pin|Iterate Input Pin]]
*** [[DiagramElements-Pin/en#Timelimit Input Pin|Timelimit Input Pin]]
*** [[DiagramElements-Pin/en#Performer Input Pin|Performer Input Pin]]
** [[DiagramElements-Pin/en#Output Pin|Output Pin]]
*** [[DiagramElements-Pin/en#Exception Output Pin|Exception Output Pin]]
*** [[DiagramElements-Pin/en#Enable Output Pin|Enable (Trigger-)Output Pin]]
*** [[DiagramElements-Pin/en#ExecutionTime Output Pin|Execution Time Output Pin]]
* [[DiagramElements-Step/en|Step]]
** [[DiagramElements-AttachmentStep/en|Attachment Step]]
* [[DiagramElements-Connection/en|Connection]]
* [[DiagramElements-PinDescription/en|Pin Description]]
* [[DiagramElements-Annotation/en|Annotation]]
* [[DiagramElements-Probe/en|Probe]]

== Tools ==

=== Debugger ===

* [[Tools Debugger/en|Debugger]]: the internal Debugger

=== Additional tools in the "Extras"-Menu ===

* [[Tools Notepad/en|Notepad]]: A postIt-like text editor and code evaluation window

* [[Tools FileBrowser/en|File Browser]]: A tool to search for and manipulate files and their contents

* [[Tools ClassBrowser/en|Class Browser]]: Expert tool to investigate and manipulate class code

* [[Tools ProcessMonitor/en|Process Monitor]]: A tool to show active execution processes (threads within expecco)

* [[Tools Transcript/en|Transcript]]: A message and trace window

* [[Tools TestSuiteDifferenceBrowser/en|Test Suite Difference Browser]]: To find differences between two test suites

=== Additional functions in the "Extras" Menu ===

* "Explorer" / "Explorer In...": opens a Windows Explorer window on one of the common directories (Windows platform only)
* "Finder" / "Finder In...": opens a Finder window on one of the common directories (Mac OSX platform only)
* Screenshot: generates a file containing a screenshot image (in BMP, PNG or TIFF format)
* [[Tools ModelTranslationEditor/en|Model Translation Editor]]: To define language-translations for model elements
* [[Tools ImportScripts/en|Import Shell or Batch Scripts]]: To generate blocks for existing test/automation scripts

=== Low level debug functions found in the "Extras"-"Debugging" Menu ===

* [[ToolsMenuFunctions#ShowAllExternalConnections/en|Show all External Connections]]: To find open handles
* [[ToolsMenuFunctions#ShutDownBridgeConnections/en|Shut Down Bridge Connections]]: To tear down leftover Java Bridge connections
* [[ToolsMenuFunctions#CloseAllSocketConnections/en|Close all Socket Connections]]: To tear down leftover Socket (interprocess communication) connections
* [[ToolsMenuFunctions#CloseAllSerialConnections/en|Close all Serial Connections]]: To tear down leftover Serial connections

* [[ToolsMenuFunctions#ShowMemoryUsageByObjectType/en|Show Memory Usage by Object Type]]: Detailed information about memory usage
* [[ToolsMenuFunctions#Memory_Cleanup/en|Memory Cleanup]]: Force memory cleanup to release unused resources

== Elementary Block API ==
* Internal Interpreters - [[Expecco API/en|Expecco API]] - Information for Elementary Block Developers
** [[Expecco API/en#JavaScript_and_Smalltalk_Elementary_Blocks|JavaScript and Smalltalk Elementary Blocks]]

* External Interpreters
** [[Expecco API/en#Groovy_Elementary_Blocks|Groovy Elementary Blocks]] -- via a bridge, possibly executed inside the SUT
** [[Expecco API/en#VisualBasic_Elementary_Blocks|VisualBasic Elementary Blocks]] -- via a bridge, possibly executed inside the SUT
** [[Python Script Code Execution/en|Python Script Code Execution]] -- Python code in an external Python interpreter
** [[Node.js Script Code Execution/en|Node.js Script Code Execution]] -- JavaScript code in an external Node.js interpreter

== Standard Library Reference ==

The following libraries are included in the base package.
No additional extension or plugin is required.

* [[Standard Library/en|Standard Library]] -- A common, domain independent library
* [[SeleniumLibrary Reference/en|Selenium Library]] -- A library to control web browsers
* [[XML Library/en|XML Library]] -- A library to parse XML documents and access DOM-tree elements
* [[Expecco Reflection Library/en|Expecco Reflection Library]] -- A library to automate expecco itself

== Interfacing to the System Under Test ==

* [[COM/OLE/en|COM/OLE]] -- How to invoke COM interfaces
* [[Corba/en|CORBA]] -- How to invoke CORBA interfaces
* [[FTP/en|FTP]] -- FTP interface
* [[HTTP/en|HTTP]] -- HTTP interface
* [[HTTPS/en|HTTPS]] -- HTTP (SSL) interface
* [[SOAP/en|SOAP]] -- SOAP interface
* [[XML-RPC/en|XML-RPC]] -- XML-RPC interface
* [[REST/en|REST]] -- REST interface
* [[Telnet/en|Telnet]] -- Telnet interface
* [[Sockets/en|Sockets]] -- Generic Low Level Socket interfaces
* [[Pipes/en|Pipes]] -- Pipes
* [[Shared/en|Shared Memory]] - Shared Memory
* [[DLL Calls/en|DLL Calls]]

== Plugins and Extensions ==

=== UI Testing ===

==== Web Browser UI Testing ====

* [[Selenium Web Test Plugin/en|Selenium Web Test Plugin]] -- Web Page Tests and Interaction (part of the base package)
* [[SeleniumLibrary Reference/en|SeleniumLibrary Reference]] -- Library reference

==== GUI Testing ====
* [[Expecco GUI Tests Extension Reference/en|GUI Browser: Common Extension for GUI Tests]] This extension provides a base for the other UI technology interfaces, and is a prerequisite (included in) the Java GUI, Mobile GUI, Qt and Windows Automation GUI plugins.

* [[Java GUI Plugins/en|Java Swing/SWT UI Testing]] These plugins provide interfaces to Java GUIs based on Swing and/or SWT.

* [[Mobile Testing Plugin/en|Mobile Testing Plugin ]] This plugin interfaces to Android and iOS mobile devices via an Appium access layer.

* [[VNC Plugin Reference/en|UI Testing via VNC]] This plugin interfaces to arbitrary applications via VNC (RFB). This allows for any application to be tested. However, the set of verifiable attributes is very limited. Therefore, this is mostly used as a fallback solution, in case no other UI-plugin is applicable.

* [[Qt Plugin Reference/en|UI Testing von Qt Anwendungen]] This plugin interfaces to Applications using the Qt UI framework.

* [[OpenETS Plugin Reference/en|UI Testing von OpenETS Anwendungen]] This plugin interfaces to Applications using the OpenETS UI framework. OpenETS ("Open Expecco Test Service") consists of a C library provided by eXept, which can be linked to the program. This library handles the communication with expecco. Using OpenETS, arbitrary C/C++ applications can be automated with expecco.

* [[WindowsAutomation Reference 1.0/en|Windows Automation GUI Access Interfacing Library]] This plugin interfaces to Windows applications via the UI Automation layer.

* [[WindowsAutomation Reference 2.0|UI Testing with the Windows Automation Library]] This plugin realizes access to Windows applications via the UI Automation layer- Version 2.0

* [[AutoIt Library/en|AutoIt GUI Interface Library]] This plugin interfaces to Windows applications via AutoIt. It is very low level, in that only a very limited set of attributes is accessible; however, it works with any window written in any UI framework and is sometimes useful, if no high level attributes (knowledge) about the underlying UI technology is available.

=== Code Execution ===
* [[Groovy Code Execution Plugin/en|Groovy Code Execution Plugin]] -- allows for Groovy code to be executed locally or inside the SUT

* [[VBScript/en|VisualBasic Script Plugin]] -- allows VisualBasic code to be executed either locally or on the SUT

* [[C# Code Execution/en|C# Code Execution]] -- executes C# code either locally or inside the SUT (.NET famework)

* [[Python Code Execution/en|Python Code Execution]] -- executes IronPython code locally or inside the SUT (.NET framework)

* [[Java Browser/en|Java Browser]] -- allows for Java classes to be browsed in the SUT

* [[Java Debugger/en|Java Debugger]] -- to debug Groovy block and other code executed by the Java Bridge in (remote) JVM

* [[SmallSense/en|SmallSense]] -- together with [[Java Browser/en|Java Browser]] provides basic code completion support for Groovy code.

=== Manual Test Support Plugins ===
* [[Manual Test Plugin/en|Manual Test Plugin]] -- guides users through manual tests
* [[Manual Test Import Plugin/en|Manual Test Import Plugin]] -- imports test specifications written in Word or Excel

=== Misc Plugins ===
* [[GembirdPowerControlPlugin Reference/en|Gembird Power Control Plugin]] -- control a power plug (part of the base package)

=== QM Interface Plugins ===
* [[PolarionPlugin Reference/en|Polarion Plugin Reference]] - automate execution from & interact with Polarion
* [[expecco ALM Plugin Reference/en|expecco ALM Plugin Reference]] - automate execution from & interact with expecco ALM
* [[HP Quality Center Plugin Reference/en|HP Quality Center Plugin Reference]] - automate execution from and interact with HP Quality Center
* [[Jira Plugin Reference/en|Jira Plugin Reference]] - interact with Jira

=== Specification Import/Export ===
* [[WSDL Service Import Plugin/en|WSDL Service Import Plugin]] -- import service actions from a WSDL service description
* [[XMI Diagram Import Plugin/en|XMI Diagram Import Plugin]] -- import XMI activity diagrams from Enterprise Architect

=== Data/Message/Document Formats ===
* [[ASN.1 Support/en|ASN.1 Support]] -- parse ASN.1 specifications; read/write/verify/modify ASN.1 encoded messages
* [[GDMO Support/en|GDMO Support]] -- read/write/verify/modify GDMO objects
* [[DTD XSD Support/en|DTD, XSD Support]] -- read type specifications
* [[SWIFT Plugin/en|SWIFT Plugin]] -- read/write/verify/modify SWIFT messages
* [[EDI Edifact Plugin/en|EDI / Edifact Plugin]] -- read/write/verify/modify EDI messages; parse message specifications in various formats;
* [[EDI Idoc Plugin/en|EDI / Idoc Plugin]] -- to be documented
* [[EDI X12 Plugin/en|EDI / X12 Plugin]] -- to be documented
* [[PDF Support/en|PDF Support]] -- read PDF file structure; generate PDF documents
* [[ODF Support/en|ODF Support]] -- read ODF file structure
* [[JSON Support/en|JSON Support]] -- encode/decode JSON messages
* [[PEG Parser/en|PEG Parser]] -- to parse arbitrary messages/texts

=== Communications/Protocols ===

* [[FTP Support/en|FTP Support]] - ftp client / ftp server / sftp client
* [[HTTP Support/en|HTTP Support]] - HTTP client / HTTP server
* [[Telnet Protocol/en|Telnet Protocol]] - client / server
* [[SSL Protocol/en|SSL Protocol]]
* [[IMAP & POP3 Support/en|IMAP & POP3 Support]]
* [[NFS Support/en|NFS Support]] - Network File System server emulation
* [[Sun RPC Support/en|Sun RPC Support]] - client & server
* [[Thrift Support/en|Thrift Support]]
* [[MQueue Plugin/en|MQueue Plugin]] - websphere/mainframe interface
* [[Serial Port Communication/en|Serial Port Communication]]
* [[Parallel Port Communication/en|Parallel Port Communication]]
* [[USB Port Communication/en|USB Port Communication]]
* [[ChipCard/SmartCard Package/en|ChipCard/SmartCard Package]] - GSM, EC, ISO7816 cards and other standards via GemPlus, Oros and other interfaces
* [[GPIB Interface/en|GPIB Interface]] - measurement device interface
* [[CanBUS Interface/en|CanBUS Interface]] - low level interface via serial or USB interface
* [[LDAP Interface/en|LDAP Interface]]
* [[COM Interface/en|OLE/COM Interface]]
* [[MQTT Support/en | MQTT Protocol]] - IoT (Internet of Things)
* [[SOME/IP]] - automotive

=== Databases ===
* [[ODBC Interface/en|ODBC Interface]] (part of the base package)
* [[ODBC Interface/en|SQLite Interface]] (part of the base package)
* [[Oracle Native Interface/en|Oracle Native Interface]]

==== NoSQL ====
* [[Cassandra Interface/en|Cassandra Interface]]
* [[CouchDB Interface/en|CouchDB Interface]]
* [[MongoDB Interface/en|MongoDB Interface]]
* [[SandstoneDB Interface/en|SandstoneDB Interface]]
* [[Goods-DB Interface/en|Goods-DB Interface]]

=== API ===
* [[Plugin API/en|Plugin API]] - information for Plugin developers

=== [[expecco Mobile Remote App/en|expecco Mobile Remote App (for Android)]] ===

== Customization ==

* [[User Defined Menu Items/en|User Defined Menu Items]]
 

== Concepts, Hints, Tips and Tricks ==

* [[expecco API/en|expecco API]]
* [[Executor/en|Executor]]
* [[Executor#Activity/en|Executor - Activity]]

* [[Generating Test Data/en|Generating Test Data]]
* [[Parametrizing Tests/en|Parametrizing Tests]]
* [[Organizing Libraries/en|Organizing Libraries]]
* [[Reimporting a Library/en|Reimporting a Library]]
* [[Uses of Tags/en|Uses of Tags]]

== Tutorials ==

* [[Testing Java Applications using Groovy blocks/en|Testing Java Applications using Groovy Blocks]]

= expecco ALM =
== Overview ==
[[expecco ALM Architecture/en|expecco ALM (Application Lifecycle Management)]]

=== Glossary ===

=== Konzepte ===
* [[expecco ALM Architecture/en|Architecture]] - overview and architecture
* [[expecco ALM Concepts/en|Concepts]] - concepts; testsuite, testdefinition, testschedule, testrun, testequipment
* [[expecco ALM Configuration & Setup/en|Configuration & Setup]] - setting up users, roles and projects

=== Release Notes ===
* [[expecco ALM Release Notes/en 1.9.5|1.9.5]]
* [[expecco ALM Release Notes/en 2.0.0|2.0.0]]

== [[expecco ALM Installation/en|Installation]] ==

== [[expecco ALM System Settings/en|Settings (System)]] ==
* [[expecco ALM System Settings LDAP/en|Login using LDAP]]

== Webinterface (HTTP) ==
* [[expecco ALM Personal Settings/en|Personal Settings]] - editor settings
* [[expecco ALM Master Menu/en|Master Menu]]
* [[expecco ALM Requirements UI/en|Requirements UI]]
* [[expecco ALM Defects UI/en|Defects UI]]
* [[expecco ALM Actions UI/en|Actions UI]]
* [[expecco ALM Tests UI/en|Tests UI]]
* [[expecco ALM Projects UI/en|Projects UI]]
* [[expecco ALM Organization UI/en|Organization UI]]
* [[expecco ALM Settings UI/en|Settings UI]]

== Mobile Monitoring App (Android) ==
* [[expecco ALM App/en|expecco ALM App]]

= Licenseservice =
== General ==
* [[License Server Overview/en|Overview]]
* [[License Server Release Notes/en|Release Notes]]
* [[Lizenzservice Installation/en|Installation]] - initial installation, license files, updates
* [[License Server Configuration & Setup/en|Configuration & Setup]] - setting up ports and users
* [[License Server Glossary/en|Glossary]]

== User Interface ==
* [[License Server License Menu/en|License Menu]]

= Smalltalk =

* http://live.exept.de Online Documentation
* http://live.exept.de/ClassDoc Class Documentation

== Packages ==
* [[SOAP/en|SOAP]]
* [[SOAP WSDL/en|SOAP WSDL]]

WindowsAutomation Reference 2.0

2018-05-28T15:11:06Z

Lv:

WindowsAutomation Reference 2.0

2018-05-28T14:53:54Z

Lv:

Datei:WindowsAutomation Library AccessBlocksModes.PNG

2018-05-28T14:49:59Z

Lv:

Datei:WindowsAutomation Library AccessBlocksExamples.PNG

2018-05-28T14:31:11Z

Lv: Lv lud eine neue Version von „Datei:WindowsAutomation Library AccessBlocksExamples.PNG“ hoch

WindowsAutomation Reference 2.0

2018-05-28T14:30:27Z

Lv:

Datei:WindowsAutomation Library AccessBlocksExamples.PNG

2018-05-28T14:30:18Z

Lv: Lv lud eine neue Version von „Datei:WindowsAutomation Library AccessBlocksExamples.PNG“ hoch

Datei:WindowsAutomation Library AccessBlocksExamples.PNG

2018-05-28T14:25:29Z

Lv:

WindowsAutomation Reference 2.0

2018-05-28T13:34:35Z

Lv:

WindowsAutomation Reference 2.0

2018-05-28T12:51:47Z

Lv:

Datei:WindowsAutomation2 Library ConnectingBlocks.PNG

2018-05-28T12:51:08Z

Lv: Lv lud eine neue Version von „Datei:WindowsAutomation2 Library ConnectingBlocks.PNG“ hoch

The Windows Automation 2 library's blocks for handling connections.

Datei:WindowsAutomation Library AccessBlocks.PNG

2018-05-28T12:49:18Z

Lv:

Datei:WindowsAutomation2 Library ConnectingBlocks.PNG

2018-05-28T11:54:37Z

Lv: The Windows Automation 2 library's blocks for handling connections.

The Windows Automation 2 library's blocks for handling connections.

WindowsAutomation Reference 2.0

2018-05-28T11:38:22Z

Lv:

WindowsAutomation Reference 2.0

2018-05-28T11:37:31Z

Lv:

WindowsAutomation Reference 2.0

2018-05-28T11:34:39Z

Lv: Die Seite wurde neu angelegt: „This is the documentation for the Windows Automation 2.0 plugin. It provides facilities to automate tests incorporating applications with a GUI based on Windo…“

GUI Testing

2018-05-28T10:33:43Z

Lv:

* [[Expecco GUI Tests_Extension Reference|GUI Browser: Gemeinsame Basis der verschiedenen GUI Test Erweiterungen]] Diese Erweiterung dient als Basis für die verschiedenen UI Technologieanbindungen. Sie ist Voraussetzung für (und beinhaltet in) den Erweiterungen für die Java GUI, Mobile GUI, Qt und Windows Automation GUI Erweiterungen.

* [[Java GUI Plugins|Java Swing/SWT UI Testing]] Diese Erweiterungen stellen Schnittstellen zu Anwendungen mit Java GUIs, basierend auf Swing und/oder SWT bereit.

* [[Mobile Testing Plugin|Mobile Testing auf Android und iOS]] Diese Erweiterung bietet Zugriff auf Mobilgeräte basierend auf Android und iOS. Die Kommunikation erfolgt über eine Appium-Schnittstelle.

* [[VNC Plugin Reference|UI Testing über VNC]] Diese Erweiterung realisiert den Zugriff auf UI-Anwendungen über die VNC (RFB) Schnittstelle. Mit dieser können beliebige Anwendungen getestet werden (sofern ein VNC-Server auf dem Zielsystem erreichbar ist), allerdings sind Attribute nur sehr eingeschränkt abrufbar. Sie dient daher vornehmlich als Fallback-Lösung, falls andere Plugins nicht zum Einsatz kommen können.

* [[Qt Plugin Reference|UI Testing von Qt-Anwendungen]] Diese Erweiterung realisiert den Zugriff auf UI-Anwendungen basierend auf dem Qt Framework.

* [[OpenETS Plugin Reference|UI Testing von OpenETS-Anwendungen]] Diese Erweiterung realisiert den Zugriff auf UI-Anwendungen basierend auf dem OpenETS Framework. OpenETS ("Open Expecco Test Service") ist eine von eXept erhältliche C-Bibliothek, die Entwickler zu ihrem C-Programm binden, und die Kommunikation mit expecco übernimmt. Damit können beliebige C/C++ Anwendungen automatisiert werden.

* [[WindowsAutomation Reference 2.0|UI Testing mit der Windows Automation Library]] Realisiert den Zugriff auf Windows Anwendungen über die UI Automation Schnittstelle - Version 2.0

* [[WindowsAutomation Reference 1.0|Windows Automation GUI Access Interfacing Library 1.0]] Realisiert den Zugriff auf Windows Anwendungen über die UI Automation Schnittstelle.

* [[AutoIt Library|AutoIt GUI Interface Library]] Bietet Zugriff auf Windows Anwendungen über AutoIt. Dies ist eine Low-Level Schnittstelle, welche nur eine eingeschränkte Sicht der Attribute von Komponenten erlaubt. Allerdings kann damit jedes GUI angesprochen werden, unabhängig von dessen darunterliegenden Technologie. Es ist daher oft hilfreich, wenn keinerlei Information über die Struktur des GUIs vorliegt.