ComponentOne, keeping itself abreast with the latest market trends and technologies, also has come out with support for CodedUI tests in its controls. That ComponentOne controls controls are officially supported in UICoder, meaning once you want to start with recording and play back of automation scripts created in UICoder, the controls would support various mouse and keyboard actions performed on them. Also they can be read quite deeply using the CodedUI Test Builder. So if you want to place control based assertions on a grid using values stored in one of the cells, and you happen to be using one of C1’s most popular grids, C1FlexGrid, rest assured, it will show up just fine in the list of controls in UIMap class.
There are some limitations though, both with the controls and UICoder, which hamper creation of some scripts or recording and play back of some actions. In this post we are going to provide some useful tips for ASP.NET and SilverLight Technologies.
Tips for ASP.NET Controls
CodedUI since the time of its launch has been mainly seen as an automation tool for Winforms application, since it is easier to read individual objects off a windows form than it is to do off a web page. Our ASP controls, on the other hand, work just as well within CodedUI scripts as well.
Tip: For web pages, what we found as a work around was to use the DOM of the page, extensively, to look for control tags and from there, manipulate our script actions and assertions.
There is only playback support for scripts in FireFox browser, that still, remains a limitation of UICoder.
Tip: As a work around, we started recording scripts in IE and played them back on FireFox by selecting it as the browser to open the webpage in, from within the TestScripts, using the following code,
BrowserWindow.CurrentBrowser = “FireFox”; // Mentioning the Browser in which script has to run
BrowserWindow win = BrowserWindow.Launch(@”<webpage name you want to open>”);
win.Maximized = true;
For a detailed description on how to go about creating CodedUI tests from scratch, you can take a look at the following blog post,
Tips for Silverlight Controls
Creating CodedUI scripts for SilverLight has always been quite tricky as not all the actions are supported and not everything can be recorded. More over, we cannot playback scripts on multiple browsers. The very basic problem is to make controls visible to CodedUI Test builder. This can be effectively solved by putting AutomationId’s for all the elements being used on the page. But still sometimes many actions (even on MS controls) are not correctly recorded, or the recording and recognizing is painfully slow in terms of performance.
One common issue that we faced was that it was not possible to click on the same control twice within the same script.
Tip: As a workaround to counter this, we refreshed pages within the scripts, so as to clear the cache in browser, and get a fresh list of controls for UICoder to perform actions on.
This work around works quite neatly in most cases. In some cases where we need to access the same control multiple times it is advised to change our designing of the page. For example, put Buttons and ComboBoxes, within “ContainerControls” or separate tags within the XAML Page.
Microsoft came out with enhanced support for CodedUI and Silverlight in Feature Pack 2 and Service Pack 1 of Visual Studio 2010. This solved a number of issues, but we found that it was quite a let-down performance wise.
For a detailed description on how to go about creating CodedUI tests from scratch, you can take a look at the following blog post:
Another important aspect of creating CodedUI Tests is the time delays between actions. While recording scripts it may not seem as useful, but it is the most important factor when we want these scripts to run successfully on multiple environments.
It is not necessary that on two test machines complete all the actions work out in the same time period and if we are not providing adequate gap between two actions, it may happen the UICoder starts looking for objects to be used to next action, when the first one is yet to be completed, thereby failing the scripts.
In this case the exceptions thrown are not of much help too since all they say is 'so and so' control not found. This does not make the scripter think on the lines of providing time periods between script actions.
Tip: The best way to tackle these kinds of exceptions is to have adequate wait time, between actions of scripts. VS2010 gives two ways of doing the same.
If you have SP1 of VS2010 installed on your system, which mostly everyone has, it is pretty easy to read the UIMap class. Double click on it in the solution explorer and it is parsed and show quite clearly, with all the individual actions and objects being used.
In this view if you right click on any action item, you can see the “Insert Delay Before” option (See image below). This would make UICoder, wait for the mentioned duration before performing this action.
Alternatively, we can also specify this for the whole UIMethod in code:
//There are three option for “WaitForReadyLevel” depending on use any one can be set
Playback.PlaybackSettings.WaitForReadyLevel = WaitForReadyLevel.AllThreads;
//Time delay is in microseconds, so depending on every action in the script we can set an average value
Playback.PlaybackSettings.DelayBetweenActions = 1000;
We shall be putting together a similar compilation of some simple tips for Winforms and WPF coded UI scripts and samples as well.
Here are some of the links which can also be useful for reference.