Avalon - CLI307: Automated UI Testing
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.
About Newsletter
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.
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.
Don't know why they're re-inventing the wheel...