Tuesday, March 1, 2016

Windows Forms/ WPF Application automation using Microsoft UI automation APIs


Microsoft UI Automation APIs, also known as the MSUIA or UIA libraries were released as a part of .NET Framework 3.0 and above. These APIs are successors of the MSAA (Microsoft Active Accessibility ) classes.
The MSUIA libraries expose control patterns for each control, actions and properties for these controls. Using these control pattern classes, MSUIA lets the users assess and  manipulate values  of controls on your system.

The Search in UIA is in a tree structure where Root Element (Desktop) is the parent of all the elements. All the windows on your desktop are Children of Root Element which will have their own children elements like button, link etc. All the children and children of children's ( I'm trying to say that all the elements in all the windows open on your system at a time) are Descendants of root element

There are many tools available to find the elements and their properties, but ideally we use the Inspect.exe. Inspect is present in the bin folder of Windows Kits (if installed) in your program files.
When you open Inspect.exe, you will see a downward tree structure with "Desktop" pane as the root and all the windows as chidren within it. When you expand a window element, you will be able to view the elements within that window.
This is how inspect window looks like:


Let's get started with using MSUIA libraries

- First thing , I would suggest start a new project in Visual Studio (ideally UnitTest Project) and try out all the classes I would be walking you through in the rest of this article.

- Secondly, download MSUIA references and add them to your project . The DLL are as following :

   1. UIAutomationProvider.dll and UIAutomationTypes.dll [ Provider API]
   2. UIAutomationClient.dll and UIAutomationTypes.dll [Client API]
   3. UIAutomationCore.dll
   4. UIAutomationClientSideProviders.dll

- Thirdly in a new class add the namespace"using System.Windows.Automation;"

Now you are ready to go.

The following few classes are important for you to know about when planning to work on these libraries.

1) AutomationElement : This is a sealed class, which saves the properties of a control in its object.
RootElement is a keyword which returns the desktop element, under which all the elements/controls are searched for.

2) AutomationElementCollection contains objects of multiple AutomationElement. If you want to find all controltype= button inside a parent element A, you can use this class object while AutomationElement always returns the first objects it finds with the properties mentioned.

3) PropertyCondition saves conditions on the basis of which an object is identified.
For your better understanding, the signature of one of the methods present in the PropertyCondition class looks like.






// takes a property name like 'Class name' , 'id', 'name' etc and its value .

4) ControlPatterns : Every control will support a/few control pattern(s). If a control supports a pattern or not, can be seen on the right hand column of Inspect.exe when you select the control. The is<patternname>Available property will be set to true. For example, for a button, the isInvokePatternAvailable property is set to true.

Every control pattern has a class in MSUIA libraries example :
GridPattern.cs
ExpandCollapsePattern,cs
InvokePattern.cs
TablePattern.cs
ValuePattern.cs

If you want to click on a button (which has invoke pattern available), perform the following steps:


Similary, if you want to enter a text in a textBox (which has value pattern available), you use the ValuePattern class object which has a method called SetValue.

To get the current properties involved with any control, you can use the property  'Current' which is a property in each Pattern class.
See the following code .

The above code snippet, shows how to create Control Pattern objects ;perform actions on them and get current values from them.

Start with taking a windows/WinForms based project and try performing the above actions on their controls.

Hope this tutorial works. Write back to me or comment for more detailed information/tutorial.

Happy learning :)

Monday, February 22, 2016

First few steps on starting a new UI automation project



Deciding on which tools to use, what kind of architecture to follow, what steps to take could be cumbersome. Hence it is very important to make a check-list for yourself when starting a new automation development project.

1) First step is making the decision of whether an application is ready to be automated or not.
As an automation engineer, have a look at the application, do basic sanity and exploratory testing of the application to understand whether the application is stable enough for automation. Find out if there is any planned big change in the application structure, and if there is, wait till after that change.

2) Understand the need of automation here. The requirements and whether the application even  requires testing enough for putting in the effort of automation.
Get the requirements in place. Ask questions like - Whether it is for the purpose of regression testing?, how much percentage of the application can be automated?, do you need an end-to-end scenario testing of the application?

3) Think ahead, and what all will be required from automation in the future. Plan your automation accordingly. Stay updated on technology, and make sure you are using the latest. Do good research on the tools available, the costs of these and the skill set required for these tools.

4) A thorough POC on which tool to pick up for the application is required. This would include trying to verify, using the different tools, which is the most efficient/ cost effective and fast way of automating your application.
Verify that all the forms/ pages and controls in the application can be identified by the tool and that you are able to perform basic actions on these. Try to automate a small scenario and see if it works. Try this with all your choices of tools and see which one fits your expectations the best. Ensure you pick the right tool.

5) Plan, prepare to work on the skill set required for using the tool you've picked up.

Of course once you are ready to start automating make an elaborate test automation plan, with the purpose of the project, all the requirements, the timelines, the estimates, what all resources required and the risks and slippages that you think may occur.
The first step is always building a great scalable framework for your automation activities if you don't have it in place already.

Saturday, February 20, 2016

Page Object Design Pattern



One of the most widely used and efficient ways to automate an application, be it web, windows, mobile or any other, is following the approach of Page Object design pattern.

A Page Object design ensures that  there is class or a separate module for each page/form which encapsulates all functionalities of that page/form.  This reduces to a great extend scope or need of code repetition of any type.

In this kind of a design, a class A of a page/form A will make sure all the objects present in that page A are defined in this class, all the properties to be accessed from this page are defined in class A and all the actions to be performed in the page , example entering data, clicking on submit, verifying a field etc. are encapsulated only in the class A in the form of methods. Whenever any action needs to be performed on this page or a property needs to be accessed from this page, an object of class A has to be created.

Let's take an example. An application has two screens :

Screen 1 contains :

'UserName' field
'Password' field
'Submit' button

On entering username and password and clicking on submit in Screen 1, the user is navigated to Screen 2.
A page object class for Screen1 would look like :







This is an example of how a simple page object class could normally look like.

Few points to remember about Page object model:

- the actions which expect the navigation to go to another screen return a type of page object class of the other screen. In the example, ClickonSubmit expects to open Screen2 , hence return type is an object of Screen2 class.

- the actions which expect no navigation, but to stay on the same screen, return a type of the same class. In the example, Enterdata expects no change in screen, hence return type is an Screen1 object.

- all actions performed in a page are limited and encapsulated to a single class.

This is just one approach, great and efficient, to follow during automation although not a mandate. Deciding on what kind of a framework to develop, which tool to use, what design patterns to follow also depend on the kind of application being automated and what is required and expected from the automation of it.


Test Automation


Test Automation is a major need for testing a software regressively before bringing any new feature in the software to live,

Test automation ensures a fast and inexpensive approach to quickly testing applications and making sure they are ready to go. It is of course a fact, without mentioning, that automation of the testing will never replace manual testing but it will make life easier especially in cases of regression testing.
This blog is to share views and talk about good standards to follow for test automation.