- CSV
[DataSource("Microsoft.VisualStudio.TestTools.DataSource.CSV", "|DataDirectory|\\data.csv", "data#csv", DataAccessMethod.Sequential), DeploymentItem("data.csv"), TestMethod]
- Excel
DataSource("System.Data.Odbc", "Dsn=ExcelFiles;Driver={Microsoft Excel Driver (*.xls)};dbq=|DataDirectory|\\Data.xls;defaultdir=.;driverid=790;maxbuffersize=2048;pagetimeout=5;readonly=true", "Sheet1$", DataAccessMethod.Sequential), DeploymentItem("Sheet1.xls"), TestMethod]
- Test case in Team Foundation Server
[DataSource("Microsoft.VisualStudio.TestTools.DataSource.TestCase", "http://vlm13261329:8080/tfs/DefaultCollection;Agile", "30", DataAccessMethod.Sequential), TestMethod]
- XML
[DataSource("Microsoft.VisualStudio.TestTools.DataSource.XML", "|DataDirectory|\\data.xml", "Iterations", DataAccessMethod.Sequential), DeploymentItem("data.xml"), TestMethod]
- SQL Express
[DataSource("System.Data.SqlClient", "Data Source=.\\sqlexpress;Initial Catalog=tempdb;Integrated Security=True", "Data", DataAccessMethod.Sequential), TestMethod]
CodedUI Blog
This is a CodedUI blog which serves as a - One stop solution blog for all CodedUI related information. Hope you enjoy this. If anyone has any information it can be shared and also if any improvements can be made please let me know. Few of the topics can be found in other blogs. My main moto is to share knowledge and also collecting the information
Tuesday 13 December 2016
Data Source Types and Attributes
Thursday 1 December 2016
How to Click or find control by scrolling page in CodedUI
How to click on control if it is visible on page and we need to scroll the page to click on it.
In CodedUI we have UITestingUtilities dll that helps us a lot in finding control or verifying control existance by providing many extended methods.
In below code sample, we have one button control on page. To click on this control manually, we need to scroll the page and then we can click on control. This can be handled through code by using EnsureClickable() method.
Here we are first making sure that the control exists by using TryFind() method and then trying to click control.
While loop added to check if more page scroll action required. Once the control is clicked the "isClickable" variable set to true, so that to break the While() loop. The exception is thrown if the control is still hidden on blocked by some other control , To handle this condition we have to catch the exception and instead of throwing it we are scrolling the page down.
Code below
BrowserWindow bw = new BrowserWindow();
HtmlButton but = new HtmlButton(bw);
//define properities for the button here
bool isClickable = false;
if(but.TryFind())
{
while (!isClickable)
{
try
{
// It ensures control is visible and clickable
but.EnsureClickable();
Mouse.Click(but);
isClickable = true;
}
catch(FailedToPerformActionOnHiddenControlException)
{
//We dont through an exception instead we scroll the page down and try again
Mouse.MoveScrollWheel(-1);
}
catch (FailedToPerformActionOnBlockedControlException)
{
{
//We dont through an exception instead we scroll the page down and try again
Mouse.MoveScrollWheel(-1);
}
}
}
}
Thursday 4 August 2016
Finding elements by JavaScript
While trying to use JavaScript to speed up the test execution, many tests would start first operation (such as selecting one option from a combo box, clicking on a link or button and etc.) several minutes after the pages loaded. This is hard to tolerate when running tests from my PC and anyone can only wait several minutes to run a single line of code.
In these cases, though CodedUI cannot step forward, instead a JavaScript can be run from command line of IE browser directly. BrowserWindow would execute JavaScript i.e. ExecuteScript() only after WaitForControlReady() returning true. Fortunately, developing JavaScript to replace native operations like Mouse.Click() could still be very helpful.
From time to time, CodedUI tests would fail to perform some very basic operations like clicking on a button or entering text to a text control. Sometimes click on a line/button of a web page, “Click” sound will be heard but the browser would simply do nothing. JavaScript would then be more effective when it operates directly on the element instead of via UI.
The key scripts are listed below:
#region JavaScript function names
public const string FindByCssFunction = "querySelector";
public const string FindByIdFunction = "getElementById";
public const string FindFirstByCssFunction = "querySelectorAll";
public const string FindFirstByClassFunction = "getElementsByClassName";
public const string FindFirstByNameFunction = "getElementsByName";
public const string FindFirstByTagFunction = "getElementsByTagName";
#endregion
public const string GetElementByIdScript = @"
var result = document.getElementById(arguments[0]);
if (result)
return result;
var frames = document.getElementsByTagName('frame');
if (arguments[1]) {
var frame = frames[arguments[1]];
if (frame.document)
return frame.document.getElementById(arguments[0]);
else
return frame.contentWindow.document.getElementById(arguments[0]);
}
for(var i = 0; i < frames.length; i ++) {
if (frames[i].document)
result = frames[i].document.getElementById(arguments[0]);
else
result = frames[i].contentWindow.document.getElementById(arguments[0]);
if (result) break;
}
return result;";
public const string FrameGetElementByIdScript = @"
var result = arguments[0].contentDocument.getElementById(arguments[1]);
return result;";
public const string GetFirstByCssScript = @"
var elements = document.querySelectorAll(arguments[0]);
if (elements.length)
return elements[0];
var frames = document.getElementsByTagName('frame');
if (arguments[1]) {
var frame = frames[arguments[1]];
if (frame.document)
return frame.document.querySelectorAll(arguments[0]);
else
return frame.contentWindow.document.querySelectorAll(arguments[0]);
}
for(var i = 0; i < frames.length; i ++) {
if (frames[i].document)
elements = frames[i].document.querySelectorAll(arguments[0]);
else
elements = frames[i].contentWindow.document.querySelectorAll(arguments[0]);
if (elements.length)
return elements[0];
}
return null;";
public const string GetClickablePoint = @"
var element = arguments[0];
var absoluteLeft = element.width/2;
var absoluteTop = element.height/2;
do {
absoluteLeft += element.offsetLeft;
absoluteTop += element.offsetTop;
element = element.parentElement;
}while(element)
var result = new Array();
result[0] = Math.round(absoluteLeft).toString();
result[1] = Math.round(absoluteTop).toString();
return result;";
public const string GetAttributeScript = @"try{{return arguments[0].getAttribute('{0}');}}catch(err){{return null;}}";
public enum FindFirstMethod
{
ById,
ByCSS,
FirstByCSS,
FirstByClass,
FirstByName,
FirstByTag,
}
The web app under test uses multiple frames as container to show different panels. To search one element with its ID, The JavaScript “GetElementByIdScript” would first search the root document, then after getting all frames, would try to iterate all frames to see if the element with specified ID could be found within one of them. The “FrameGetElementByIdScript” is used to search a single frame only give element ID. The “GetFirstByCssScript” provides a more generic means to search element with CSS selectors which however would normally return an array and actually only the first one is expected. The “GetAttributeScript” is used to retrieve attribute from a given element, notice that when there is an error catched, it shall return “null”.
To reuse the above scripts with different methods (by ID, by Class, by Name and etc.), the FindFirstMethod enum is defined and the default value ById would be used as below:
public static HtmlControl FindControl(this BrowserWindow window, string locatorKey, FindFirstMethod method = FindFirstMethod.ById, string frameName = "body")
{
if (window == null || !window.WaitForControlReady(DefaultWaitReadyTimeMillis))
throw new Exception("Browser is not specified or is not ready after " + DefaultWaitReadyTimeMillis / 1000 + "s.");
string script = null;
switch (method)
{
case FindFirstMethod.ById:
script = GetElementByIdScript;
break;
case FindFirstMethod.ByCSS:
script = GetElementByIdScript.Replace(FindByIdFunction, FindByCssFunction);
break;
case FindFirstMethod.FirstByCSS:
script = GetFirstByCssScript;
break;
case FindFirstMethod.FirstByClass:
script = GetFirstByCssScript.Replace(FindFirstByCssFunction, FindFirstByClassFunction);
break;
case FindFirstMethod.FirstByName:
script = GetFirstByCssScript.Replace(FindFirstByCssFunction, FindFirstByNameFunction);
break;
case FindFirstMethod.FirstByTag:
script = GetFirstByCssScript.Replace(FindFirstByCssFunction, FindFirstByTagFunction);
break;
default:
throw new NotSupportedException();
}
object result = null;
Stopwatch watch = new Stopwatch();
watch.Start();
while (result == null && watch.ElapsedMilliseconds < 20 * 1000)
{
result = window.ExecuteScript(script, locatorKey, frameName);
//To cope with the bug of BrowserWindow..ExecuteScript()
var optionList = result as IList<object>;
if (optionList != null)
{
var child = optionList.FirstOrDefault(o => o != null) as HtmlControl;
result = (child == null || !child.Exists ) ? null : child.GetParent();
}
}
return result as HtmlControl;
}
The script would then be finalized by replacing some keywords and run by a BrowserWindow instance. Noticeably, when trying to get a HtmlComboBox, CodedUI would wrongly return an array of its option children and that is why there is some special treatment to get a single HtmlControl.
CodedUI only defines BrowserWindow with virtual object ExecuteScript(string script, params object[] args), to make it easier to use, there are two helper methods introduced to target one specific control with or without extra parameters:
public static object RunScript(this HtmlControl control, string script)
{
if (control == null)
throw new Exception("Failed to locating the control?!");
BrowserWindow window = control.TopParent as BrowserWindow;
if (window == null || !window.WaitForControlReady(DefaultWaitReadyTimeMillis))
throw new Exception("Browser is not specified or is not ready after " + DefaultWaitReadyTimeMillis / 1000 + "s.");
return window.ExecuteScript(script, control);
}
public static object RunScript(this HtmlControl control, string script, params object[] extraArguments)
{
if (control == null)
throw new Exception("Failed to locating the control?!");
BrowserWindow window = control.TopParent as BrowserWindow;
if (window == null || !window.WaitForControlReady(DefaultWaitReadyTimeMillis))
throw new Exception("Browser is not specified or is not ready after " + DefaultWaitReadyTimeMillis / 1000 + "s.");
var len = extraArguments.Length;
object[] arguments = new object[len + 1];
arguments[0] = control;
for (int i = 0; i < len; i++)
{
arguments[i + 1] = extraArguments[i];
}
return window.ExecuteScript(script, arguments);
}
Then some helper functions are quite straightforward:
public static string AttributeByScript(this HtmlControl control, string attributename)
{
return control.RunScript(string.Format(GetAttributeScript, attributename)) as string;
}
public static string InnerText(this HtmlControl control)
{
return control.RunScript("return arguments[0].innerText;") as string;
}
public static string InnerHTML(this HtmlControl control)
{
return control.RunScript("return arguments[0].innerHtml;") as string;
}
public static string OuterHTML(this HtmlControl control)
{
return control.RunScript("return arguments[0].outerHtml;") as string;
}
public static Point ClickablePointByScript(this HtmlControl control)
{
object result = control.RunScript(GetClickablePoint);
List<object> position = (List<object>)result;
return new Point(int.Parse(position[0].ToString()), int.Parse(position[1].ToString()));
}
Their meanings are explained below:
- SomeControl.AttributeByScript(attributename): to get Attribute of a control by attribute name;
- SomeControl.InnerText(): would retrieve everything within the opening and closing tag of the control as innerText as used in section “Evaluating rows of a table”. It could be tuned to get displayed text.
- SomeControl.InnerHtml()/OuterHtml(): returns InnerHtml and OuterHtml respectively.
- SomeControl.ClickablePointByScript(): I have tried this to get the clickable point to avoid waiting CodedUI to be ready to click some link/button, but it doesn’t return before the target control is really ready.
The more useful methods are listed here:
public const bool HighLightControlBeforeOperation = true;
public static void ClickByScript(this HtmlControl control)
{
control.ShowByScript();
if (HighLightControlBeforeOperation)
control.HighlightByScript();
control.RunScript("arguments[0].click();");
}
public static void SetValue(this HtmlControl control, string valueString)
{
control.RunScript("arguments[0].value = arguments[1];", valueString);
}
public static void ShowByScript(this HtmlControl control)
{
control.RunScript("arguments[0].scrollIntoView(true);");
}
public const string DefaultHighlightStyle = "color: green; border: solid red; background-color: yellow;";
public static void HighlightByScript(this HtmlControl control)
{
//*/ Highlight by script: changing the style of concerned element
var oldStyle = control.AttributeByScript("style");
control.RunScript("arguments[0].setAttribute('style', arguments[1]);", DefaultHighlightStyle);
System.Threading.Thread.Sleep(DefaultHighlightTimeMillis);
if (oldStyle != null)
{
control.RunScript("arguments[0].setAttribute('style', arguments[1]);", oldStyle);
}
else
control.RunScript(string.Format("arguments[0].removeAttribute('style');"));
}
Their meanings are explained below:
- SomeEdit.SetValue(valueString): is used to input text to Edit control even when it is not displayed yet.
- SomeControl.ShowByScript(): would make the control visible for further operation/observation.
- SomeControl.HighlightByScript(): to modify the style of the target control to make it highlighted for several seconds.
- SomeControl.ClickByScript(): might be the most useful method to fix tests. The ShowByScript() would be called to make the control visible, then HighlightByScript() would be called to mark it outstanding before perfroming “someControl.click()”. This design is out of intention: by performing operations 3 times(scrolling once, changing styles twice), it is very unlikely to miss clicking on the target control.
To use these scripts are also quite simple, taken Click() for example: for some problematic Mouse.Click(someControl), just replacing them with “someControl.ClickByScript()” would make many failed tests passed.
Source: http://www.codeproject.com/Articles/876476/Tips-to-fix-CodedUI-tests
TryFind vs WaitForControl(Ready/Exist)
TryFind() changed the test execution. The reason is that TryFind() would return true/false immediately when pages are still loading and its returned value would heavily depend on the responsiveness of the web server, so some tests would be fixed by simply replacing it with WaitForControlExist() which would block the current thread until timeout specified by default PlaybackSettings.WaitForReadyTimeout.
However prefer specifying timeout setting explicitly by calling WaitForControlReady(int millisecondsTimeout) or WaitForControlExist(int millisecondsTimeout). Somebody might accustomed with Playback.Wait(int thinkTimeMilliseconds) or Thread. Sleep(int millisecondsTimeout), but they might wait unnecessarily long.
In addition, if combined with Assertion as be;pw:
Assert.IsTrue(someElement.WaitForControlReady(60*1000)); //Wait for 1 min
Unexpected delay could be highlighted immediately.
There are multiple WaitForControl() functions defined with UITestControl, some of them could be very helpful but are usually neglected, for example:
- WaitForControlCondition(Predicate<UITestControl> conditionEvaluator, int millisecondsTimeout), combined with LINQ, provides a very powerful means to evaluate any status of the target control.
- WaitForControlPropertyEqual(string propertyName, object propertyValue, int millisecondsTimeout) enables tester to monitor changes of any attribute of the control effectively.
- bool WaitForControlNotExist(int millisecondsTimeout), combined with Assert.IsTrue(), could be used to evaluate operations have successfully caused the page changing to another state.
- bool WaitForControlExist(int millisecondsTimeout) and bool WaitForControlReady(int millisecondsTimeout) should be used from time to time before performing solid operations like clicking, selecting or typing. Usually, the former is good enough especially when such operations would be carried out only when the browser/control is ready. But they might return different values for a specific control: usually WaitForControlExist() would return true when the target control is displayed, but in some of my projects, WaitForControlReady() would return true several minutes after WaitForControlExist() returning true.
Sunday 10 April 2016
Database Testing with CodedUI
Lets discuss about the Database Testing with CodedUI (C#) with some sample code
Connection String plays a key role in connecting to the database
Which has a different format for different Databases like Oracle,SQL etc
Which has a different format for different Databases like Oracle,SQL etc
//Below code will login and open the DB connection.
string connetionString = “Data Source=DBSeverName;Initial Catalog=DBName;User ID=UserName;Password=DBPassword”;SqlConnection connection = new SqlConnection(connetionString);
connection.Open();
Once the DB connection is setup, we need to define a sql Command for executing and Sql Datareader for reading the results of the command
Once the results are read by the data reader, it is loaded into a DataTable
//Below code will help to execute the Select query.
String Selectquery = “Select FirstName from Emp where EmpID in (01)”;
SqlCommand command = new SqlCommand(Selectquery, connection);
SqlDataReader reader = command.ExecuteReader();
DataTable dataTable = new DataTable();
dataTable.Load(reader);
Once the results are read by the data reader, it is loaded into a DataTable
String Selectquery = “Select FirstName from Emp where EmpID in (01)”;
SqlCommand command = new SqlCommand(Selectquery, connection);
SqlDataReader reader = command.ExecuteReader();
DataTable dataTable = new DataTable();
dataTable.Load(reader);
Once the data is loaded into the datatable, all we need to do is verify with the expected output
//Below code will help to verify the data which above code fetch from the particular table.
String rowText;
rowText = DB.dataTable.Rows[0][DB.dataTable.Columns[0]].ToString();
if (rowText.Contains(“Mayank”))
{
Console.WriteLine(“FirstName is macthing with expected result”);
}
else
{
Console.WriteLine(“Verification is not passed”);
}
//Below code will help to verify the data which above code fetch from the particular table.
String rowText;
rowText = DB.dataTable.Rows[0][DB.dataTable.Columns[0]].ToString();
if (rowText.Contains(“Mayank”))
{
Console.WriteLine(“FirstName is macthing with expected result”);
}
else
{
Console.WriteLine(“Verification is not passed”);
}
After the verification, Close the connection
//It will close the connection.
connection.Close();Thursday 7 April 2016
Using a App.config file to have different Sections in CodedUI project
To make coded UI tests to work in different environments, or to have different configuration values for different test methods to override the source of data file, a config file can be setup rather than a data source.
Things to be done to achieve this
Things to be done to achieve this
- You’ll need to add a reference to the System.Configuration assembly for the solution
- Then add the custom elements to app.config file (which is added to test project) TestSiteConfigurationData section name in the app.config file
- Create configuration data class for a custom section in App.Config TestSiteConfigurationData.cs
- Create the Helper class file for reading the data from configuration data class TestSiteConfigurationHelper.cs
- Call the helper class in the Codedui Project and read the values from config file under your custom section
You might face an issue with some wrong value entered for the type of section in the app.config file
<configSections>
<section name="TestSiteConfigurationData"
type="Configuring_Sections.TestSiteConfigurationData,Configuring Sections"/>
</configSections>
Configuring_Sections.TestSiteConfigurationData - <ProjectNamespace>.<ConfigurationDataClassName>
Configuring Sections - the solution dll name i.e your CodedUI project name
Find the sample project implementing the above attached
Happy coding :)
Monday 10 August 2015
Limit TestMethod Timeout in CodedUI
Sometimes when we have Test Methods which run for long time, we tend to see the below kind of exceptions and TestMethod execution stops.
"Test 'TestMethod_Name' exceeded execution timeout period."
By default Execution time for a test method is 60mins.
This test execution timeout can be changed as per our requirements.
It can be either changed in the Settings file or else
First way is to Set a limit time for execution which is as shown below
[TestMethod]
[Timeout(6000)]
public void TestMethodName()
{
}
Second is to set infinite time limit when we dont know how much time the execution is going to happen or if we are expecting the execution to run completely irrespective of the time
[TestMethod]
[Timeout(TestTimeout.Infinite)]
public void TestMethodName()
{
}
Subscribe to:
Posts (Atom)