Tag Archives: 0.8.0 Preview 2

0.8.0 Preview 2: wanted richer output?


Again and again, it’s not going to end. People ask me ‘why Metro UI testing doesn’t work from PowerShell ISE?’

PowerShell ISE and powershell.exe are Microsoft’s tools, they have no relation to Metro UI testing. Technically, Microsoft guys can build ISE and powershell.exe to make them uiAccess’ible. However, don’t wait this: why should they build a host for my cmdlets? To help compete with their Coded UI? I sooner believe that they will write their own UI cmdlets in v3 or v4 (as they usually answer to PowerGUI features, for example), than they do something specific for 3rd party cmdlets.

The other side of coin is that I’m not going to write one more code editor with debugging capabilities. I’d like to, but this is a time-consuming task. Not to say that an editor of appropriate quality is not so easy to write up.

That’s a dilemma: we can run PowerShell over Metro UI, but we can’t work deeply with variables and output.

0.8.0 Preview 2 solves this partly. Now, output is partially supported. The list of what is supported:

  • string output (code: “string”)
  • string output for objects (code: (Get-UIAWindow 0n calc*).Current | Out-String)

Write- cmdlets are not supported in this version. Possibly, they will be supported later.

Here is a sample:

[UIAutomation.Preferences]::EveryCmdletAsTestResult=$true
[UIAutomation.Preferences]::OnSuccessDelay = 0;

Start-Process calc
Get-UIAWindow -n calc* | Get-UIAButton -n 1 | Invoke-UIAButtonClick;
(Get-UIAButton -n add | Invoke-UIAButtonClick).Current.AutomationId;
(Get-UIAButton -n 1 | Invoke-UIAButtonClick).Current | Out-String;
Get-UIAWindow -n calc* | Get-UIAButton | Set-UIAFocus | Set-UIAControlKeys -Text "1{+}1{=}"
'Get-UIAWindow -n calc* | Out-String; ->'
Get-UIAWindow -n calc* | Out-String;
'(Get-UIAWindow -n calc*).Current | Out-String;'
(Get-UIAWindow -n calc*).Current | Out-String;

"now test should fail"
Get-UIAWindow -n "non-existing window" -Seconds 2
Get-UIAWindow -n calc* | Get-UIAButton -n 10 | Invoke-UIAButtonClick;

Output is shown as light-blue lines. It returns:

  • the button 1 (Invoke-UIAButtonClick returns)
  • the automation id of the button Add (again, the same cmdlet returns)
  • AutomationElementInfo (i.e., .Current). This is the button 1 again.
  • further, after an empty string, there are string lines to help you compare what means to put an AutomationElement and an AutomationElementInfo to the Out-String cmdlet.

It’s not proper way to debug your scripts, though it’s the only way for now.

0.8.0 Preview 2: double squares help to visualize controls better


Controls belong to a big hierarchy. What may be the reason to highlight only two levels of controls if, in practice, there might be ten or twenty levels in the hierarchy?

The pictures show what the double-highlighting is. The inner square is over the control of interest, whereas the circumscribing one is over its parent.

However, things suddenly change when you put the cursor over WPF applications, its (WPF’s) derivatives and HTML:

This is a rather typical case: we are seeing a button or a link and, at the same time, the topmost control is a text.

The same story in Metro UI applications:

Here it is seen even better:

and here too:

The name of the button is not ‘Permissions’ as we could think, the name is ‘Back’.

At the end, there is a brilliant example:

There are TWO things on top of the button! This is the out-of-the-box Mail application.

%d bloggers like this: