Feature requests

Coordinator
Feb 13, 2012 at 7:59 PM

The wish list

Coordinator
Mar 1, 2012 at 10:27 PM
Edited Mar 1, 2012 at 10:28 PM

Three features:

1) Get-UIAWindows -PID 1234 is the same as Get-UIAWindow -ProcessName (Get-Process -Id 1234).ProcessName

2) Get-UIAControl -Handle 12345678 is awaiting a wider explanation

3) caching the Automation tree for speeding up the powershell code

We'll conduct some experiments the next week or so, however, there should be understanding that if you have usability (small pieces of code with user-friendly names, with parameters - i.e. cmdlets), you should pay in some other way, somehow.

Consider the typical case: we test an applications that works with network or web services, a database or the environment.

we get the main window: Get-UIAWindow

Cmdlets are not human beings: if they must cache the tree, they will cache the tree. Excluding the case where caching is manually controlled through a set of parameters. Okay, we cache the tree. now.

After that we start some processing.

One minute is gone, or twenty. We have the cache. Should we use the cache? For example, the application under test gathered the data, especially into its controls. There is no worth in our cache. The application changed significantly.

 

Possibly, caching is a great feature if you need fast clicking. I mean combinatorial tests like calc.exe. The most of control are not subject of change all the time of the test suite, only the output box is being changed (okay, calc.exe also has from two to four modes). These tests may be the reason to cache the tree.

Nonetheless, the user can cache it manually:

$calc = Get-UIAWindow -p calc;

$b1 = Get-UIAButon -n 1; $b2 = Get-UIAButon -n 2; $b3 = Get-UIAButon -n 3;

$b1 | Invoke-UIAButtonClick;

Furthermore, you can wrap it inside functions:

$script:calc = Get-UIAWindow -p calc;

$script:b1 = Get-UIAButon -n 1; $script:b2 = Get-UIAButon -n 2; $script:b3 = Get-UIAButon -n 3;

function sum { param($a, $b)

 function selectButton { param($b) switch ($b){# return the button by name}}

$null = $button1 = selectButton $a;

  $null = $button2 = selectButton $b;

$null = Invoke-UIAButtonClick -InputObject $button1

$null = Invoke-UIAButtonClick -InputObject $buttonPlus

$null = Invoke-UIAButtonClick -InputObject $button2

$null = Invoke-UIAButtonClick -InputObject $buttonEquality

$result = Get-UIATextBox ....

return $result;

}

$sum = sum 1 2

Mar 3, 2012 at 12:39 AM

I just changed OnSuccessDelay to 5 and now its fast enough. The only thing I need now is to find the UIAwindow main object by processID, MainWindowHandleHWND or process object!

I also have a problem. When I run the script under SchTasks in the background, it doesn't work.

Coordinator
Mar 3, 2012 at 8:03 AM

Okay, using concrete things like handles and PIDs makes sense in cases where the application under test (AUT) is a page in the browser, an MDi child or frame, or several instances of the AUT are permitted simultaneously.

However, using PID or process is not allmighty thing:

Start-Process calc -PassThru | Get-UIAWindow 

will work (not in the current version), but

Get-UIAWindow -pid (Start-Process c:\windows\system32\mmc.exe -PassThru).Id

never will work since start-process returns not the same PID that we can see in the Task Manager.

 

 

UIAutomaiton module/library (and GUI applications at all) won't work in the background, or on the locked screen, on before the user logged. I never investigate deeply into it, just dare think that it can't create the RootObject.

In our tests we use hosts where the user already logged-in or with auto logon and no screensaver enabled.

Possibly, it will work through a service interacting with the desktop (in some future release), but the user should be logged-in and the Windows GUI should be seen.