Starting with Automated Testing in .Net

Contributed by admin on 23 Aug 2013

A few days back, I saw a few computer screens and something caught my eye. Fields in Winforms were automatically getting filled up with data and firing click events. This intrigued me and awoke my curiosity. Several questions rose to my mind:

What could this be? Why is it required?

After days of pondering over it, the answer suddenly clicked and everything fell into place: it was automated test records using Coded-UI.

To put in a simple way, Coded-UI is a tool that is available with Microsoft Visual Studio - Ultimate or Premium version. This tool enables us to create automated tests in order to validate UI controls, functions of Windows and web applications.

To begin with, you can visit

http://msdn.microsoft.com/en-us/library/dd286681(v=vs.100).aspx

And know more.

In this article, I would walk you through the challenges that I faced in performing automation tests, viz how to identify hidden/mouse-over controls, how to validate row/column values of a grid, how to repeat the recorded action, how to split/edit/remove action items, etc.

While performing a task to validate records in a grid, since we cannot validate each and every row, in order to validate all the records in a grid, I came out with the below script to validate each individual row in a given table. I added the below script in UIMap.cs:

public partial class UIMap

{

public void ValidateGridTable()

{

//Get the instance of grid table by using cross hair (assert)

WinTable uIGridTable = this.UISearchVehicles1d100Window.UIItemWindow3.UIGridTable;

UITestControlCollection tc = uIGridTable.Rows;

foreach (WinRow wr in tc)

{

int index = 0;

UITestControlCollection wc = wr.Cells;

foreach (WinCell wcell in wc)

{

if (index == 5)//identifies the column for assertion, points to column-6

{

string neworused = wcell.Value;

Console.WriteLine(neworused);

if (neworused != “New”)//Ensures that the column contains ‘New’, if not assertion will fail.

{

Assert.Fail(“Record/s are exists other than new”);

}

//Similarly, Add condition for value is deleted/not deleted

}

index = index + 1;

}

}

}

}

Tip: UIMap.cs file is used to add custom code as shown above.

Above code validates the 6th column of all the rows. The 6th column should contain column value as ‘New’ in all rows for the test to be successful, failing which the test would fail and return “Few Record/s exist other than new”.

Similarly, one can validate if a particular value is removed in listbox/combobox as shown:

public void AssertComboBoxItems()

{

//Get the instance of the combobox

WinComboBox uIABCcodeComboBox = this.UIVendors1ceuVendoraccWindow.UIItemWindow.UIABCcodeComboBox;

UITestControlCollection itms = uIABCcodeComboBox.Items;

foreach (var itm in itms)

{

if (itm.Name == “ValueToCheck”)//check if the item is removed or not, if not return fail

{

Assert.Fail(“Value is still exists, Item is not removed!”);

}

}

}

Initially, we failed to identify hidden controls/hidden forms/mouse-hover menu items, because these controls were invisible as soon as one clicked outside. To validate any hidden controls, use keyboard shortcut key Ctrl+I. The same is illustrated below with the example of validating menu items of Google chrome:

Step - 1: Start recording

Step - 2: Click on ‘Menu’

Step - 3: Save record

And then point your mouse over the menu border and press Ctrl+I such that blue border appears over all the menu items as shown below and save it.

Once validated work is saved, the following script validates whether a given menu item is identified or not:

public void ValidateMenuItems()

{

//Run the dependent record to populate menu-items before invoking this method.

WinMenu uIDropDownMenu = this.UIItemWindow.UIDropDownMenu;

UITestControlCollection tcc = uIDropDownMenu.Items;

bool isFound = false;

foreach (UITestControl tc in tcc)

{

Console.WriteLine(tc.Name);//to see output of console.writeline, click on output  link in the test results pane

if (tc.Name == “ValueToCheck”)//Check menu item exists or not

{

isFound = true;

}

}

if (isFound == false)

{

Assert.Fail(“Required menu item is not found”);

}

}

Points to Ponder:

a. Do not rename the Coded UI Test Map file (i.e. UIMap1.uitest). You might lose all the test cases recorded in this.

b. Recorded method should preferably act on a single page or a form or a dialog. Create a new test method for each new page, form or dialog. Or split the recorded method into many small records by double clicking UIMap.uitest, which opens Coded-UI test editor that allows you to view/edit recorded methods/actions and control properties.

c. Do not comment / modify code in UIMap.Designer.cs because changes could be overwritten on creating new recordings or assertions.

Each line in the action recordings in the c# or VB code that the Coded UI Test Builder generates represents a step (Action item) from the action recording. This will be added to the UIMap.Designer.cs file and the supplied method name would be enclosed. This method will be called from the CodedUITest1.cs file.

When more number of test cases are recorded, the UIMap.Designer.cs file grows bigger and may not be easy to maintain. Thus, it is always advisable to create a separate UIMap.uitest file and bring up the coded-UI-Builder by right clicking, so that all the recordings will be associated to it.

By now, I am sure you are clear with the distinct differences and the role played by CodedUITest.cs, UIMap.Designer.cs, UIMap.uitest and UIMap.cs files.

I was once asked a question: How to validate a set of input values and its expected values i.e., how to repetitively run test method/test case in iterative mode for a given set of records?

The answer to that is here.

While performing tests, playback may fail to locate a particular control/assert value if the application is talking to the database. This is because the records in a database might have been modified / deleted while performing the UI actions. Hence, the playback might have failed to validate. It is therefore advisable to restore the database in the test-initialize and test-cleanup methods. The test life cycle of a single test method according to which every test method runs is of the following order:

[TestInitialize] -> [TestMethod1] -> [TestCleanup]

[TestInitialize] -> [TestMethod2] -> [TestCleanup]

[TestInitialize] -> [TestMethod3] -> [TestCleanup]

[TestInitialize] -> [TestMethod……] -> [TestCleanup]

 

The TestInitialize and TestCleanup methods would look like this:

[TestInitialize()]

public void MyTestInitialize()

{

DBRestore();//Custom code for DBRestore() method;

}

[TestCleanup()]

public void MyTestCleanup()

{

DBRestore();//Custom code for DBRestore() method;

}

Sometimes, we may need to perform a clean-up activity or make a call to specific recorded UI actions only when a test fails. This can be achieved as shown below:

[TestCleanup()]

public void MyTestCleanup()

{

if (this.TestContext.CurrentTestOutcome== UnitTestOutcome.Failed)

{

//make a call desired record;

this.UIMap.CloseApp();

DBRestore();

}

}

I hope I have addressed all the absolutely essential requisites to start/master an automated test in .Net.

-Contributed by Lokesha.M.

Visit us at Neevtech.com to know more about our offerings.

Tags: , , , , , , , , , , , , , , , , , , , , , , , , , , , , , ,

facebook comments:

Leave a Comment