Scott Hanselman

Avalon - CLI307: Automated UI Testing

October 29, 2003 Comment on this post [4] Posted in PDC | NUnit
Sponsored By

If you've ever written a complex Windows UI you may have thought about ways to automate testing of these frameworks.  It was easier in the old days, when every control had a Window Handle that you could get ahold of.  Then more and more controls were owner draw, painted or just magic.  Regardless, automated UI testing is a hassle.

In the last few years I've been all over NUnit.  Just as my dentist says “if you don't floss, don't bother brushing,“ I say, “if you don't Unit Test, don't bother coding.“  But the exception is usually UI.

I'm in a talk on Avalon's Automated UI Testing Framework.

The Avalon UI Testing Framework appears to expose the UI components as an Object Model, that they are calling “Control Patterns” that expose the behavior of the controls.

He's brought a Command Prompt up.  He brought up the Windows Device Manager and clicked on it.

The Command Prompt then displays:

[Tree View] [Has Children]
Patterns = I:Selection

then he types “children” and the Device Manager tree expands.

The Command Prompt says:

Patterns - I:Invoke, IHierarchyItem. I:ExpandCollapse. I:SelectionItem

he also checks out a Combo Box and it says

Patterns - I:ExpandCollapse.

This means that rather than exposing the controls directly to the UI Testing code, it exposes the BEHAVIOR.  So, in OOP terms, a ComboBox and a Tree Control both implement “ExpandCollapse.”  But it's not that simplistic.  It's really about behavior.

Think about this:  If you were using a 3rd party control, you'd have to use that library's proprietary APIs to manipulate it.  With the Windows UI Automation framework the publisher of that control will expose behaviors.  If it's a funky Outlook Bar, perhaps it exposes ExpandCollapse also. 

You can query these controls for their behavior, ala “Reflection.”  Makes me think of how cool it was 8 or so years ago when I saw Spy++.  Except rather than presenting a physical “tree” this framework presents a logical, practical tree.  (The guy in front of me works for Infragistics.  I can only guess what awesome UI Controls they are going to build.  They kick much tush.)

The namespaces (alpha) are MSAvalong.Windows.Automation.  This framework supports ALL LEGACY controls, including VB, WinForms, Win32, etc.  There is also a complete Security Model so your testing software can't be used by the powers of darkness like .VBS files.

Along with this Logical Tree, you get all Properties, Events, Control Patterns and all Input (Mouse, Pen, Keyboard, etc).  Plus, it supports filtering, so you don't get messages shouting at you.

Rather than using the Class Name (and there are thousands) to identify a control and switch on how to test it, you think about the essense of the control and it's behavior.  For example, if you're testing software doesn't know what a control is, it asks it and hears “Oh, you're clickable? And expandable?” and you write tests appropriately.

(Awesome, he was just going to start a demo, but the screen saver locked his machine.  He can't remember the password...right now we're looking at a Longhorn security screen as he tries to log in...ouch...I know what this feels like.  He's going to reboot. Oy.)

About Scott

Scott Hanselman is a former professor, former Chief Architect in finance, now speaker, consultant, father, diabetic, and Microsoft employee. He is a failed stand-up comic, a cornrower, and a book author.

facebook twitter subscribe
About   Newsletter
Hosting By
Hosted in an Azure App Service
October 30, 2003 0:50
Same thing that the Active Accessibility interfaces have done for several years now. Blind people trying to access any GUI have the same sorts of issues that testing tools do. They need to know "What is this thing? How does it relate to the other things around it? What does it DO? What is its state? etc." Back when I worked in the accessibilty group at MS (1996-1998) one of the developers had written an rlogin-type text app that would let you see the windows desktop and navigate it through those interfaces. you'd connect, type "ls" and it would say "desktop". CD into desktop, ls, see the contents. CD into apps, dialogs, etc.

Don't know why they're re-inventing the wheel...
October 30, 2003 3:36

Do you think the new UI framework allows to cut the cost of having a physical person doing the routine work daily ? Checking that test scripts still fail where they got to fail, not elsewhere? I believe you set a lot of expectations for the framework.
October 30, 2003 13:16
I DO think that it will make life easier for the physical people who test UI. It's just like when NUNit and automated unit testing started to gain favor - it didn't replace actual people who debug and test, it just made their lives easier and less tedious. My expectation is that we'll always need people to analize the results of these tests, we just won't need them to click on the buttons. They'll spend more time reading test reports and reproducing bugs.
October 31, 2003 0:58
We aren't advertising it as such, but, UI Automation is the replacement for MSAA and it is being built by the Accessibility team at MS. When we talked to developers such as screen reader manufacturers and application developers about MSAA it was clear that MSAA could not stretch to cover the demands of computing that the coming decade will bring. Especially for people with disabilities.

Given the value that testers derived from MSAA, we decided we would get far better penetration of the accessibility framework if we achieved it through promoting the benefit to developers, testers and the companies they work for. That way everyone benefits.

Comments are closed.

Disclaimer: The opinions expressed herein are my own personal opinions and do not represent my employer's view in any way.