Monthly Archives: November, 2012

Turned a year!

Just remembered that the PowerShell testing suite turned a year. As it believed, approx. on November 28th, 2011, the result of a programming mistake, of course (a piece of code didn’t work in PowerShell, just a usage mistake), the decision to write up C#-cmdlets has been made. 🙂

Since then, our frameworks have changed significantly. It was only UIAutomation which was the root of the suite. Now, there are several frameworks published and several versions upcoming.

Shortly, I’d drop a word about the Software Testing Using PowerShell team plans. From the features that are almost ready to those that are only in mind. What will the upcoming winter bring to us?


  • on fail, the Invoke-UIA[ControlType]Click cmdlets will try Win32 click by default. This behavior (the user wants it click and it clicks) is most awaiting (thanks to JohnQuest for the idea).
  • the Set-UIA[ControlType]Text cmdlets will check the result and try to use SendKeys on a failure
  • the Set-UIAControlKeys cmdlet will try several times to put text into the input field, checking the result
  • UIAutomationSpy are going to produce more useful code. Moreover, the code produced is going to be faster. How? When possible, UIAutomationSpy will set the -Win32 parameter, what, in certain situations, accelerates tests significantly (working with controls near grids and listviews is slow; this can be healed by using Win32 handles).
  • UIAutomationSpy will finally check code that it generates (sometimes what can be got by hovering over is not the same that can be got by searching in the Automation tree).
  • at least ten pages of documentation as what is published is like a mad mix
  • setup for the module
  • Java Access Brigde (that has not been tried yet)
  • we will try to use UIA2 if it’s possible to combine two UI Automation technologies


  • support for ChromeOptions, InternetExplorerOptions and FirefoxProfile
  • fast-working ‘named’ cmdlets Get-Se[TagName]
  • cmdlets for working with tables
  • SeleniumSpy
  • in a perspective, support for other browsers


  • TestLink add-in (missing functionality)
  • TFS add-in
  • working with test cases in SQLite, TestLink, various files


  • EC2 and S3 cmdlets to allow automated test lab deployment and execution


  • a small set of cmdlets allowing us to start/stop/suspend/snapshot guests


  • these days we are working on harnessing a Dependency Injection framework. By now, SePSX is partially sitting on Autofac 2.6 and we are also experimenting with NInject 3 in other projects. TLAddin has benefited from using Moq. The reasons we are working on not a business-understood features are such:
  1. the number of tests is growing and the testing cycle should be running every several minutes. Hundreds of tests we already have are for daily framework verification (they take twenty minutes or more, what is critical for us). On the opposite, a hundred of unit tests we have already had take less than five seconds (and around seventeen seconds does Gallio take to get the consciousness at the start of testing)
  2. we need more through-out testing of our code

Test Case Management: TestLink add-in beta

Just to inform that the first part of what was planned for the TestLink add-in is done. The post that is expected here is now on the project page. Why? Some bugs are in this beta, that are not worth being published in the blog.

In addition, the add-in has less cmdlets that we wanted to publish. However, it’s better to release software as frequent as possible, than not to release until some dubious point of ‘the final version’. There’s no final version in the open source world. 🙂

I suspect that there will be questions raised on what the api key is. The picture should shed some light (I have only one instance of TestLink to experiment on, so that I don’t know whether your instance have such feature or don’t).


Note: this beta is available only for .NET 3.5.


Projects’ roadmap’s gotten some dates

The recently published roadmap now contains schedule for upcoming functionality. As time continues, more features’ll get exact dates where only month is written now.

Daily automation: Execution plan for UI Automation?

Have you tried to debug GUI or UI Automation scripts? It’s possible, of course, however this activity is often like making a mountain out of a molehill. Why?, may you ask. Because, because you need to run part of your scripts, or the whole suite, in the debugging mode, and this disturbance is, most often, from a single error.

It might be time-consuming. It’s not so pleasant: you need to interrupt your activity and do something another. Maybe, insert more Write-Host or Write-Verbose statements. Or extend the log. Or run the code inside command-line or GUI-based debugger.

Well, something simple you can now do directly from your script! A couple of months ago, the most of cmdlets (I’m about he UIAutomation module) could return only one object. Now, cmdlets return  all objects that match. Even absolutely all. This is a typical behavior. This is also a problem: imagine the following hypothetical code: you get a window, after that you want to get one or more panes, and, finally, buttons. Say, Close and Cancel.

Your code looks like:

ipmo [path]\UIAutomation.dll
Get-UIAWindow -n "window name" | Get-UIAPane | Get-UIAButton -n C*;

Suddenly, you drove into an error. What? Error? I see the buttons, you think. The answer is simple: you’ve gotten two or three panes, but only one pane contains these buttons. You are given an error: the second and the third panes admitted that they lack buttons.

What would you do to resolve this? You need somehow learn which pane is yours. Here comes the Execution plan. What is it? I sure, many of us already know what an execution plan in MS SQL is. I was very excited about it, when, more than a decade ago, I’ve been achieving MCDBA. It’s how your queries will work and how long.

If you have never heard about it, several google results are worth being visited now: the search result.

Returning to our panes and buttons, we can now discuss what our plan consists of. UIAutomation 0.8.2. offers highlighter squares of ten colors for ‘generations’ of controls and numbers that allow you learn the order controls were output.

What is the thing a ‘generation’ of controls? I called so a wave of output. In our example, generation one is the window itself (it will be bordered and numbered 1). The second generation is panes (another color and numbers 2 in their upper-down corners). Finally, the third generation is buttons, also in another color.

Let’s run this code:

ipmo [path]\UIAutomation.dll
Start-Process calc -PassThru | Get-UIAWindow | Get-UIAButton; Get-UIAMenuItem; Get-UIAComboBox; Get-UIAEdit;

Here is how it looks like:

If we drag the window from under the ‘mesh’ of squares, what will be seen:

Number at the lower-right corners of squares follow the steps they have appeared:

  1. Get-UIAWindow
  2. Get-UIAButton
  3. Get-UIAMenuItem
  4. Get-UIAComboBox
  5. Get-UIAEdit

This may help in a complicated situation when you don’t know what path in the Automation tree your code walks.

Finally, there is a problem with PowerShell 2.0, or even powershell.exe -version 2. Thus, this feature is for PowerShell 3.0 running in the 3 mode.

%d bloggers like this: