How to install and use?

May 25, 2012 at 11:36 PM

Hi

Where can I find a simple tutorial on how to start running this tool and doing simple things like finding select boxes and doing button clicks?

May 28, 2012 at 1:42 PM

How about checking Documentation?

Coordinator
May 28, 2012 at 3:01 PM

Hello,

as I noticed, to my surprise, there's no in the world a free book where people could find information how to install PowerShell and how to import a module. There are a number of books about PowerShell v.1.0 or about specifics like Remoting, nonetheless, to learn how to install PS 2.0 you need pay money. ;) Despite the millions of copies of Windows 7 sold.

Writing about 'how to install PowerShell 2.0' is an actually boring subject to me (it's Microsoft's duty as I think to publish such things). Windows XP/2003 have some requirements, Vista has other, on a Windows 7 box you need only check a feature, somewhere you need add support for ISE...

In the cloud, where the documentation exists, I added short chapter about how to install the module (paths, the command, typical caspol settings for loading the module via network), the Get-Window chapter is done, and I hope to finish today or tomorrow the Get-[Control] chapter. This will be a starter's reference.

To describe the topic is really arduous, because it relates heavily on Microsoft's object model that is often hidden from testers' eyes under an automated test tool.

 

Briefly, start your try with this:

1. run PowerShell (please find out in the Internet how to run PowerShell on your system), this time run it by selecting Run As Administrator

run the following comamnd 

Set-ExecutionPolicy -ByPass or Set-ExecutionPolicy -RemoteSigned or Set-ExecutionPolicy -Unrestricted command

(for most applications you'll need only run PowerShell as is, however sometimes, for example for testing services.msc, you need to run it as Run As Administrator or under domain admin credentials)

2. load the module (UIAutomation.dll is the main part, TMX.dll is a module for organizing results, UIAutoamtionAliases.dll contains additional aliases if needed)

issue the following command:

ipmo .....full...path....to....dll...\UIAutomation.dll

ipmo .....full...path....to....dll...\TMX.dll

3. to check that all is OK run the following

gmo UIA*

the output should contains some funcitons like these:

ModuleType Name                                ExportedCommands
---------- ----                                ----------------
Binary     UIAutomation                        {Start-UIACacheRequest, Stop-UIACacheRequest, Get-UIAActiveWindow, Ge...

4. If you need to automate this process, consider learning the topic "PowerShell profiles" and simply add to a profile you preferred to the ipmo lines.

 

I'll just now put this post to the Documentation page (at the project). I hope that no longer than tomorrow I'll publish the first documentation in a single doc (install, Get-UIAWindow, Get-UIA[Control]).

 

May 28, 2012 at 6:57 PM
Edited May 28, 2012 at 6:58 PM
xinliu wrote:

Hello,

as I noticed, to my surprise, there's no in the world a free book where people could find information how to install PowerShell and how to import a module. There are a number of books about PowerShell v.1.0 or about specifics like Remoting, nonetheless, to learn how to install PS 2.0 you need pay money. ;) Despite the millions of copies of Windows 7 sold.

Writing about 'how to install PowerShell 2.0' is an actually boring subject to me (it's Microsoft's duty as I think to publish such things). Windows XP/2003 have some requirements, Vista has other, on a Windows 7 box you need only check a feature, somewhere you need add support for ISE...

In the cloud, where the documentation exists, I added short chapter about how to install the module (paths, the command, typical caspol settings for loading the module via network), the Get-Window chapter is done, and I hope to finish today or tomorrow the Get-[Control] chapter. This will be a starter's reference.

To describe the topic is really arduous, because it relates heavily on Microsoft's object model that is often hidden from testers' eyes under an automated test tool.

 

Briefly, start your try with this:

1. run PowerShell (please find out in the Internet how to run PowerShell on your system), this time run it by selecting Run As Administrator

run the following comamnd 

Set-ExecutionPolicy -ByPass or Set-ExecutionPolicy -RemoteSigned or Set-ExecutionPolicy -Unrestricted command

(for most applications you'll need only run PowerShell as is, however sometimes, for example for testing services.msc, you need to run it as Run As Administrator or under domain admin credentials)

2. load the module (UIAutomation.dll is the main part, TMX.dll is a module for organizing results, UIAutoamtionAliases.dll contains additional aliases if needed)

issue the following command:

ipmo .....full...path....to....dll...\UIAutomation.dll

ipmo .....full...path....to....dll...\TMX.dll

3. to check that all is OK run the following

gmo UIA*

the output should contains some funcitons like these:

ModuleType Name                                ExportedCommands
---------- ----                                ----------------
Binary     UIAutomation                        {Start-UIACacheRequest, Stop-UIACacheRequest, Get-UIAActiveWindow, Ge...

4. If you need to automate this process, consider learning the topic "PowerShell profiles" and simply add to a profile you preferred to the ipmo lines.

 

I'll just now put this post to the Documentation page (at the project). I hope that no longer than tomorrow I'll publish the first documentation in a single doc (install, Get-UIAWindow, Get-UIA[Control]).

 

Cool Thanks.

Small typo though Set-ExecutionPolicy -Unrestricted should be Set-ExecutionPolicy Unrestricted (removed the dash) otherwise it won't work.

 

Can't wait to see the document on how to actually use your library.

May 28, 2012 at 7:14 PM

Is there a way to deselect a button?

I did this

 

Get-UIAWindow -pn calc | Get-UIAButton -AutomationId '131' -Name '1'| Invoke-UIAButtonClick

But on my windows 7 machine I still see the dotted outline of the button.

 

http://imageshack.us/photo/my-images/600/screenshot010uye.jpg/

http://imageshack.us/photo/my-images/205/screenshot009lc.jpg/

 

The first image is how it what happens when I run the command. It selects the "1" button. The second images shows what happens when I close or minimize the calculator.

Coordinator
May 28, 2012 at 7:23 PM

Oops, dashes are typos, definitely.

If you loaded the library and the gmo (get-module) UIA* command returned some functions, you can delve into testing right now.

Now, you need to determine whether your application can be tested with the module (and with the MS UI Automation library).

run the following at your PowerShell prompt (assuming that your application is running):

Get-UIAWindow -Name 'your app window title'

this command should return some output similar to what the following command returns:

Start-Process calc -PassThru | Get-UIAWindow # this code starts a process and passes the process object via pipeline to the Get-UIAWindow cmdlet

# as there is no more code, the Get-UIAWindow cmdlet simply returns the window of the process to the command prompt

If this step works for you, try the following:

Start-Process calc -PassThru | Get-UIAWindow | Get-UIAButton -Name 1 | Invoke-UIAButtonClick

# this code start a process, passes it (the object of the process) to the Get-UIAWindow cmdlet

# the Get-UIAWindow cmdlet get the window of the process and passes it further via the pipeline

# the Get-UIAButton cmdlet receives the window and performs the search for a button with name '1'

# finally, if the button is found, the Get-UIAButton retruns it to the Invoke-UIAButtonClick cmdlet.

If your application is supported, things are simple as it can be nowhere else, PowerShell is very intuitive environment with good code-completing funcitonality.

 

Here you should ask, how to determine which commands (cmdlets, spell it command-lets) you need to use.

run the following after the module is loaded

Get-Command -Module UIA* *Button* # to find all the command that work with button

Get-Command -Module UIA* *TextBox* # there's no need to explain the command? ;)

Get-Command -Module UIA* *Click* # clicks on controls that support clicks

Get-Command -Module UIA* # to list all the cmdlets the module provides

Of course, this is a free project with traditional lack of documentation, some commands are not ready yet and so on. Nevertheless, I'd suggest you start right now, because PowerShell in general and the module particularly is a matter of hand-working. It can be learnt by hands.

I'll publish documentation today (tomorrow, sooner), however you need to understand that documentation is not a piece of cake, and not just a post here. It should contain many pitfalls that MS UI Automation has (for example, some controls don't do what you'd expect. So that there should be a lot of recommendations how to fix or avoid this, and Microsoft doesn't provide rich troubleshooting guide :( ). I mean that the full documentation is a matter of weeks (if no months) and should include a lot, including people's feedback for various kinds of applications).

I'd suggest also, as the next step, to visit the blog http://SoftwareTestingUsingPowerShell.com that has a cookbook style to find out how to deal with several types of controls. All the posts are based on standard Windows applications.

Coordinator
May 28, 2012 at 7:28 PM
Edited May 28, 2012 at 7:31 PM

Oo, you has started. That's good.

The red square is just help for you. You can switch it off. It never even touches your app. ;)

At the PowerShell prompt run the following:

[UIAutomation.Preferences]::

and press tab. Every press the tab shows the next system variable. Variables called 'Highlight' help you control this square. You can switch it off by running the command:

[UIAutomation.Preferences]::Highlight = $false

Technically, the square are four forms :) Try to use UIAVerify (a project here, at codeplex, by Microsoft's guys), it shows controls as a tree, and has similar square.

May 28, 2012 at 7:31 PM
Edited May 28, 2012 at 7:32 PM

I understand. I am sure as this very useful library gets more popular more people will start writing tutorials on it and there will be more documentation on it.

 

I will check out those commands. I am also using your UIAutomationSpy to figure out controls though I don't know what -AutomationId is or if that is a random number.

I tried to run [UIAutomation.Preferences]::Highlight = $false through powershell but I still see the highlighted control.

 

When I just do this

[UIAutomation.Preferences]::Highlight I get "false" back.

Coordinator
May 28, 2012 at 8:05 PM

There is no functionality to lit off the 'selection'. The command Highlight = $false switches off only further use of the square. The square is gone if you close the session.

You can switch off the square at the start of your PowerShell session, for example, in a PowerShell profile (there are six types of them :))

Also, there are primitive profiles (sets of settings). By default, the user works in the Presentation profile. It displays the square and has a half-second's delay between cmdlets.

For unattended execution, there is the Normal profile. It doesn't show the square and has no delays. I'd recommend you to use the Presentation profile at the time you are learning the module and the time you are projecting tests. And using with zero delays may be dangerous for test execution: sometimes things like context menu are slow and your tests may simply fail if menu has a delay before test finds it.

It looks slightly awkwardly, but works:

[UIAutomation.Mode]::Profile = [UIAutomation.Modes]::Presentation # recommended until you are familiar enough

[UIAutomation.Mode]::Profile = [UIAutomation.Modes]::Normal # for unattended execution

[UIAutomation.Mode]::Profile = [UIAutomation.Modes]::Debug # with biggest delays

 

Coordinator
May 28, 2012 at 8:14 PM

There are several tools to investigate into controls and the MS UI Automation object model:

UISpy - a tool within Windows SDK

Inspect - also a good tool, can be found in Windows SDK

UIAVerify - it's my favorite tool. It can foolow the focus or get what it's hovering over. Sometimes, it fails.

Spy++ - shipped with Visual Studio (not Express), less usable. You can use it

AccEvents - Windows SDK. I don't use it, some people use.

UIAutomationSpy - it's my tool. It shows what is under the mouse cursor in the language that PowerShell understands

It can also store the code line in the clipboard. The next version will have richer capabilities and, probably, I'll add the recorder to it.

Now, there IS a recorder. It's not brilliant, but it can help somehow.

run at the PowerShell prompt the following command:

Start-UIARecorder -noc -nos -nou -wri -Seconds 20

and use the mouse to hover over application of your interest. After twenty seconds, it should open two text files: the recording file with full paths to the control and its shorter version (sometimes, the longer version can be invaluable).

May 29, 2012 at 7:52 PM

Do I have to import the .dlls each time? I noticed everytime I open up a new powershell console I always have to import the modules in again.

I still have to try with the squares removing and see if that works.

Coordinator
May 29, 2012 at 8:08 PM

Yes, it's the logic: PowerShell loads automatically only the engine.

If you need to load modules or make some settings, PowerShell supports files (these are like autoexec.bat for PowerShell or auto_open macro for Excel) called profiles. They are simple scripts, however, there is the difference: PowerShell load them every session.

Here is a good article: http://vmin.wordpress.com/2012/05/28/understanding-the-six-powershell-profiles-technet-blogs/

 

In practice, PowerShell support command-line execution from PowerShell scripts as well as from *.bat/*.cmd files. Tests often require to be run independently and, under these requirements, runs look like

powershell.exe -file .... or powershell.exe -command ...

where settings can be stored in separate or mutual files...

 

Maybe, there'll be time when the module settings will be also stored in the config XML file. I'm planning to write an utility that will provide a GUI to settings and store them in config files. This is an idea, no more, since it's not very usable to have several config files per module dll.

 

The first version of the documentation is posted as a link on the Documentation page.

May 29, 2012 at 9:18 PM
xinliu wrote:

Yes, it's the logic: PowerShell loads automatically only the engine.

If you need to load modules or make some settings, PowerShell supports files (these are like autoexec.bat for PowerShell or auto_open macro for Excel) called profiles. They are simple scripts, however, there is the difference: PowerShell load them every session.

Here is a good article: http://vmin.wordpress.com/2012/05/28/understanding-the-six-powershell-profiles-technet-blogs/

 

In practice, PowerShell support command-line execution from PowerShell scripts as well as from *.bat/*.cmd files. Tests often require to be run independently and, under these requirements, runs look like

powershell.exe -file .... or powershell.exe -command ...

where settings can be stored in separate or mutual files...

 

Maybe, there'll be time when the module settings will be also stored in the config XML file. I'm planning to write an utility that will provide a GUI to settings and store them in config files. This is an idea, no more, since it's not very usable to have several config files per module dll.

 

The first version of the documentation is posted as a link on the Documentation page.

So in my powershell script I write I will always have to have this in it

ipmo .....full...path....to....dll...\UIAutomation.dll

ipmo .....full...path....to....dll...\TMX.dll

Coordinator
May 29, 2012 at 9:35 PM
chobo2 wrote:

So in my powershell script I write I will always have to have this in it

ipmo .....full...path....to....dll...\UIAutomation.dll

ipmo .....full...path....to....dll...\TMX.dll

There are three ways:

1) use line(s) in a script(s)

2) write a module. It's common practice to put the functionality you use more than several times to a module and load module if necessary. Loading the libraries can also be added to there, the module.

3) use a PowerShell profile. However, if your tests run on several hosts, all the hosts should have such profile.

This is absolutely normal to load modules or .NET libraries directly if your code needs it. Similarly to any scripting language, Python, for example - don't you need to load modules there?

 

The last year we tried to use FitNesse with our product. FitNesse is not a good solution for products that are one long scenario for the whole life of the installation, and our use was such:

we divided the functionality accordingly to user stories, and each story started as

start /wait /minimized powershell.exe -noprofile -command {c:\testscript.cmd param1 param2; exit;}

just a bit more complicated than the above sample. The file, testscript.cmd in our sample, runs a script *.ps1, which in turn loads the module. The module, a set of high-level functions like Invoke-RootNodeClick or Invoke-Aciton, loads libraries (other modules).

Here I would provide a piece of advice: if you need the speed, your tests should run quickly, load the libraries one time and avoid stopping errors.

If time is not the goal, load libraries/modules so many times as you need for your tests.

Jul 3, 2012 at 10:41 PM
xinliu wrote:

Hello,

as I noticed, to my surprise, there's no in the world a free book where people could find information how to install PowerShell and how to import a module. There are a number of books about PowerShell v.1.0 or about specifics like Remoting, nonetheless, to learn how to install PS 2.0 you need pay money. ;) Despite the millions of copies of Windows 7 sold.

Writing about 'how to install PowerShell 2.0' is an actually boring subject to me (it's Microsoft's duty as I think to publish such things). Windows XP/2003 have some requirements, Vista has other, on a Windows 7 box you need only check a feature, somewhere you need add support for ISE...

In the cloud, where the documentation exists, I added short chapter about how to install the module (paths, the command, typical caspol settings for loading the module via network), the Get-Window chapter is done, and I hope to finish today or tomorrow the Get-[Control] chapter. This will be a starter's reference.

To describe the topic is really arduous, because it relates heavily on Microsoft's object model that is often hidden from testers' eyes under an automated test tool.

 

Briefly, start your try with this:

1. run PowerShell (please find out in the Internet how to run PowerShell on your system), this time run it by selecting Run As Administrator

run the following comamnd 

Set-ExecutionPolicy -ByPass or Set-ExecutionPolicy -RemoteSigned or Set-ExecutionPolicy -Unrestricted command

(for most applications you'll need only run PowerShell as is, however sometimes, for example for testing services.msc, you need to run it as Run As Administrator or under domain admin credentials)

2. load the module (UIAutomation.dll is the main part, TMX.dll is a module for organizing results, UIAutoamtionAliases.dll contains additional aliases if needed)

issue the following command:

ipmo .....full...path....to....dll...\UIAutomation.dll

ipmo .....full...path....to....dll...\TMX.dll

3. to check that all is OK run the following

gmo UIA*

the output should contains some funcitons like these:

ModuleType Name                                ExportedCommands
---------- ----                                ----------------
Binary     UIAutomation                        {Start-UIACacheRequest, Stop-UIACacheRequest, Get-UIAActiveWindow, Ge...

4. If you need to automate this process, consider learning the topic "PowerShell profiles" and simply add to a profile you preferred to the ipmo lines.

 

I'll just now put this post to the Documentation page (at the project). I hope that no longer than tomorrow I'll publish the first documentation in a single doc (install, Get-UIAWindow, Get-UIA[Control]).

 

I'm trying to get 0.7.12 to work on Win8 RC (8400) and am getting the below error when I try to import the modules. 

PS C:\Windows\system32> ipmo 'C:\Program Files\_1\UIAutomation.dll'
ipmo : Could not load file or assembly 'file:///C:\Program Files\_1\UIAutomation.dll' or one of its dependencies.
Operation is not supported. (Exception from HRESULT: 0x80131515)
At line:1 char:1
+ ipmo 'C:\Program Files\_1\UIAutomation.dll'
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : NotSpecified: (:) [Import-Module], FileLoadException
    + FullyQualifiedErrorId : System.IO.FileLoadException,Microsoft.PowerShell.Commands.ImportModuleCommand

Can anyone tell me what I'm doing wrong?

Coordinator
Jul 3, 2012 at 11:16 PM
Edited Jul 3, 2012 at 11:21 PM

Hi hrp27,

which package of three (.NET35, .NET40, for.Metro.testing) do you use?

As you use the %ProgramFiles% folder, I should suppose you have downloaded the 'for.Metro.testing' package?

If so, it seems that you have not installed the certificate.

I tested right now all three packages (from my hard drive, from where they were packaged and posted) on a Windows 8 English x86 box with the certificate installed. All three ipmo'ed well.

 

As a simple test, please try to import the .NET40 version.

Otherwise, if you have not installed the certificate, follow this post's pictures: http://softwaretestingusingpowershell.com/2012/06/01/metro-automation-getting-started/

Jul 3, 2012 at 11:43 PM
xinliu wrote:

Hi hrp27,

which package of three (.NET35, .NET40, for.Metro.testing) do you use?

As you use the %ProgramFiles% folder, I should suppose you have downloaded the 'for.Metro.testing' package?

If so, it seems that you have not installed the certificate.

I tested right now all three packages (from my hard drive, from where they were packaged and posted) on a Windows 8 English x86 box with the certificate installed. All three ipmo'ed well.

 

As a simple test, please try to import the .NET40 version.

Otherwise, if you have not installed the certificate, follow this post's pictures: http://softwaretestingusingpowershell.com/2012/06/01/metro-automation-getting-started/

Thanks for the quick reply.  I get the same error when I try the .NET40 version. 

PS C:\Windows\system32> ipmo 'C:\Program Files\_2\UIAutomation.dll'
ipmo : Could not load file or assembly 'file:///C:\Program Files\_2\UIAutomation.dll' or one of its dependencies.
Operation is not supported. (Exception from HRESULT: 0x80131515)
At line:1 char:1
+ ipmo 'C:\Program Files\_2\UIAutomation.dll'
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : NotSpecified: (:) [Import-Module], FileLoadException
    + FullyQualifiedErrorId : System.IO.FileLoadException,Microsoft.PowerShell.Commands.ImportModuleCommand

I did install the certificate and I see it in the trusted root authority.  Also, I saw someone mention PoshConsole and tried that.  It seems to work in PoshConsole but not in the standard PowerShell ISE.  I can ipmo in Posh and no error.  I can even Show-UIAMetroStartScreen and that works.  I would like to use PowerShell ISE.  Any suggestions?

Coordinator
Jul 3, 2012 at 11:57 PM

May it be the case that your powershell.exe simply does not work? I have on one Windows 8 host something like that. After, possibly, installing some software that requires a .NET Framework (I don't know what is the cause), PowerShell on the host got broken. However, PowerShell ISE works.

 

If you are going to test anything except Metro UI, any powershell host would match your goals (I advised a month ago to use PoshConsole. Since that I wrote a very simple host aka UIAutomationSpy. PoshConsole is not so stable to be used for substantial amount of time, I think).

If you want to test a Metro UI app, you will run tests from UIAutomationSpy or, soon, UIARunner. Other hosts can't hover over the Metro UI. (If you have two monitors, I have never tried this on Windows 8, there is a chance that ANY powershell host could see Metro UI controls. But, I'm not sure in that).

If you need to get familiar with the module, you can use any Windows with .NET 3.5 or higher.

Coordinator
Jul 4, 2012 at 12:15 AM

hrp27, is you folder %ProgramFiles% local? This error may be the result of loading a library (dll) from a network location.

For example, your user profile is on network, and folder virtualization maps Program Files to your profile, therefore to a network place.

On the other hand, if PoshConsole consumes, it's not a network location.

 

What the Get-ExecutionPolicy cmdlet says? Try to set Set-ExecutionPolicy RemoteSigned or even Set-ExecutionPolicy ByPass (running powershell As Administrator) and load thereafter.

Jul 4, 2012 at 12:20 AM
xinliu wrote:

hrp27, is you folder %ProgramFiles% local? This error may be the result of loading a library (dll) from a network location.

For example, your user profile is on network, and folder virtualization maps Program Files to your profile, therefore to a network place.

On the other hand, if PoshConsole consumes, it's not a network location.

 

What the Get-ExecutionPolicy cmdlet says? Try to set Set-ExecutionPolicy RemoteSigned or even Set-ExecutionPolicy ByPass (running powershell As Administrator) and load thereafter.


I tried both ByPass and RemoteSigned and still no ipmo.  I'm getting the same behavior on 2 other systems. 

Coordinator
Jul 4, 2012 at 12:43 AM
Edited Jul 13, 2012 at 7:58 AM

Okay, try to load TMX.dll or 3rd party, for example, pscx.dll from http://pscx.codeplex.com/releases/view/45101 

We need to understand whether it is  the problem with only UIAutomation.dll, or any dll can't be loaded.

Coordinator
Jul 4, 2012 at 9:50 PM

The root of the problem was in attemps to use binary files that was downloaded from the Internet. Windows 8 prevents you from using such easy ways.

First of all, you need to download files to your user's folder and unpack there.

After that you need to unblock libraries (executables are ready for use immediately after you clicked the UAC confirmation).

Only after finishing the steps described above, you can put the files to the 'Program Files' folder.

The whole story is posted here: http://softwaretestingusingpowershell.com/2012/07/04/metro-automation-the-first-step/

Jul 5, 2012 at 6:51 AM
xinliu wrote:

The root of the problem was in attemps to use binary files that was downloaded from the Internet. Windows 8 prevents y!!ou from using such easy ways.

First of all, you need to download files to your user's folder and unpack there.

After that you need to unblock libraries (executables are ready for use immediately after you clicked the UAC confirmation).

Only after finishing the steps described above, you can put the files to the 'Program Files' folder.

The whole story is posted here: http://softwaretestingusingpowershell.com/2012/07/04/metro-automation-the-first-step/


Wow, thanks xinliu!  That solved the problems I was having.