That's a sparse August calendar over there on the right....
So things have settled down somewhat (I don't have to work both days of the weekend...).
UI Test Automation Under Windows
Today I started working on an MSAA (Microsoft Active Accessibility)-based .NET component to drive Windows UI with the aim of using it to do automated testing (among other things). After playing around with a few different approches I have settled on this one:
I'm implementing the component using C++ and managed extensions. I use the managed extensions primarily to provide the public interface to the component so that all .NET languages can use it. Behind the public interface I'm doing everything using native code. I'm doing it this way primarily because I don't know enough about .NET interop to do what I need to do (Plus, I'm well versed enough in what I have to do on the native side to write that code pretty easily. The hard part so far has been marshalling native data to the managed side of things).
When testing UI, you basically need to do 2 things for any particular action: you have to 1) locate the object you want to query or manipulate and 2) do the query or action. My approach to locating UI objects is to use a combination of Win32 and MSAA calls.
A Little Windows UI Background Info...
UI objects in Windows can be found using a tree structure with the root node being the desktop (actually, there can be multiple desktops but for simplicity's sake I'm ignoring that possibility for now). There are two different tree hierarchies that can be used to navigate to UI objects in Windows: 1) the window hierarchy (using Win32 HWND's) and 2) the MSAA hierarchy (using IAccessible COM object pointers).
The window hierarchy is composed of window objects. The API's to traverse and manipulate this hierarchy have been around for a long time (all the way back to Win16...). Since this stuff dates back to when machine resources were precious, this stuff is fast and lightweight. The only problem is that there have been technologies that have been implemented that don't use Windows windows for UI. Windowless COM controls are one example. HTML pages are another. Dialogs implemented by MS Office applications are a third. These technologies draw their own controls on a pane that is a single Windows window. The Win32 APIs can't get you to these kinds of non-Windows-window-based controls and windows.
Enter MSAA. There is a group in Microsoft that is very concerned about computing for the disabled (check out http://www.microsoft.com/enable). Accessibility aids (like screen readers for the blind) traditionally used the Win32 API to query and manipulate UI but the newer technologies that bypassed standard Windows windows (and in the process the Win32 API) made this impossible. So the accessibility group defined a technology that would allow custom UI implementers to provide a way to programmatically work with their UI components.
It turns out that the needs of people making accessibility aids and the needs of people trying to implement automated testing tools are quite similar so this technology can be used to implement automated UI testing on Windows.
If you want to explore these two UI technologies there are tools that you can use to browse them. On the Win32 side you can use Spy++ (this tool ships with Visual Studio). The MSAA hierarchy can be looked at using the MSAA tools (available here).
More on my UI navigation approach next time...
11:53:27 PM 
|
