Tag Archives: 0.8.0 Preview 4

Daily automation: eliminating the fragility of tests. Part 3


Many of us faced the situation when a window is gone and a testing tool hits the air for long time. The testing tool tries to get a control, a next control, and so on. Every attempt takes time.

UIAutomation had the remedy for the problem for relatively long time. This feature has never been widely known, so that it’s time to tell you what it is and how it works.

Task: minimize the time that UIAutomation spends on controls of a window that failed to appear.

Requirements: demonstrate how to use the technique with default settings.

Solution: you don’t need to do anything to benefit from this technique in case if a window of your interest is gone:

ipmo [path]\UIAutomation.dll
Start-Process calc -PassThru | Get-UIAWindow;
[UIAutomation.Preferences]::Timeout
[UIAutomation.Preferences]::AfterFailTurboTimeout
Get-UIAWindow -Name calc1 # non-existing window
[UIAutomation.Preferences]::Timeout
[UIAutomation.Preferences]::AfterFailTurboTimeout
Get-UIAWindow -Name calc* # this call get a window
[UIAutomation.Preferences]::Timeout
[UIAutomation.Preferences]::AfterFailTurboTimeout

After we ran this sample, we have the following output:
5000 – the default timeout
2000 – the AfterFailTurboTimeout
2000 – the timeout equals to AfterFailTurboTimeout. This is because calc1 has not been caught and the default timeout was considered as too long to wait for nothing
2000 – the AfterFailTurboTimeout
5000 – the default timeout was restored after the test have got a window
2000 – the AfterFailTurboTimeout
Note: this funcitonality has been broken in 0.8.0 Preview 4 (more accurately, 0.8.0P4 was released despite the fact that several unit tests have not been fixed. Just because this functionality is not widely known and never used explicitly).

Internally, UIAutomation checks that [UIAutomation.CurrentData]::CurrentWindow is $null and [UIAutomation.CurrentData]::LastResult also is $null.

Well, what about controls? Imagine the case you have a window and a child window or a control failed to appear.

This problem is not so obvious as the ‘no such window’ problem. ‘One control is gone’ is a typical case during the development cycle. Nonetheless, some controls are vital for the whole test. For this, a new parameter is here: -IsCritical. Let’s see how it works:

ipmo [path]\UIAutomation.dll
Start-Process calc -PassThru | Get-UIAWindow | Get-UIAButton -Name 1
[UIAutomation.Preferences]::Timeout
Start-Process calc -PassThru | Get-UIAWindow | Get-UIAButton -Name 10
[UIAutomation.Preferences]::Timeout
Start-Process calc -PassThru | Get-UIAWindow | Get-UIAButton -Name 10 -IsCritical
[UIAutomation.Preferences]::Timeout
[UIAutomation.CurrentData]::LastResult
Start-Process calc -PassThru | Get-UIAWindow | Get-UIAButton -Name 1
[UIAutomation.Preferences]::Timeout
Start-Process calc -PassThru | Get-UIAWindow | Get-UIAButton -Name 1 -IsCritical
[UIAutomation.Preferences]::Timeout

Below is the output:
5000 – the default timeout
5000 – the default timeout as the -IsCritical parameter has not been used
2000 – the turbo timeout (thanks to the -IsCritical parameter)
5000 – the default timeout (after the first control that has been caught successfully)
5000 – IsCritical does nothing if there wasn’t a problem

The general rule is to use the -IsCritical parameter for child windows, default buttons and controls like combo boxes and radio buttons if their state blocks you from going forward.

Advertisements

0.8.0 Preview 4 is available to download


UIAutomation 0.8.0 Preview 4 has been uploaded to http://uiautomation.codeplex.com/releases/view/93118 and now you can try new output.

Except a couple of issues in the functionality that is not widely used, all our unit tests are green. Nonetheless, we’d recommend you to play with this release with some care: there might be combinations of code where new cmdlets may behave slightly differently.

For example,

Get-UIAWindow ... | Get-UIAButton ... | %{ $_ | Read-UIAControlName ... }

with this release can be written as

Get-UIAWindow ... | Get-UIAButton ... | Read-UIAControlName ...

 

0.8.0 Preview 4: no more restrictions on pipeline


In response to a request on the project forum, UIAutomation now supports outputting all the items that engine returns. How did it work earlier? Get-UIAWindow returned only one window, so did Get-UIA[ControlType] cmdlets.

How the most of traditional cmdlets work? Get-Process returns all the processes that match or simply all processes in the system. Get-ChildItem returns all the file system items in the current folder or wherever the -Path parameter said, if no filter supplied. Even Selenium cmdlets return all web elements that match a condition.

Thus, to meet standard practices, UIAutomation now returns all what match. Get-UIAWindow returns all ‘Calculator’ windows if the command a user issued was

Get-UIAWindow -Name calc*

Note that the [UIAutomation.CurrentData]::CurrentWindow variable (i.e. the current window is the last window object in the pipeline).
Get-UIAButton returns all buttons of the window if the least restrictive wildcard is given:

Start-Process calc -PassThru | Get-UIAWindow | Get-UIAButton -Name *


Pattern cmdlets (Invoke-, Get- and Set-) and Read- cmdlets accept such output. Even Get-UIA[ControlType] -Win32 parameter returns not the only object as earlier but all that match. Note that -Win32 does not understand types of controls and returns all whose names match the condition:

Start-Process calc -PassThru | Get-UIAWindow | Get-UIAButton -Name * -Win32 | Read-UIAControlName


The sample outputs names of all controls with handles.

Finally, if some of you readers wanted to click all the buttons at a time (I wanted), here is the script:

Start-Process calc -PassThru | Get-UIAWindow | Get-UIAButton -Name * | ?{ ($_ | Read-UIAControlName) -ne 'Close' } | Invoke-UIAButtonClick

%d bloggers like this: