CodedUITests and C1SilverLight

April 08 2011

Ever since Microsoft came out with Visual Studio 2010 with the Integrated Coded UI testing feature in it, we have been working on making our controls more compatible with it. There has been growing popularity of UICoder in the automation field due to the simplicity of generating and more maintainable tests. It has features that, until recently, were only desired, but never available in Automation tools. Nevertheless, this blog is not about how great VS2010 and UICoder is (since that is why we are already where we are); this is an endeavor to educate the methods in which we can create CodedUI tests for our SilverLight applications and how the current batch of our controls are performing in such a test. The History Initially, when VS2010 was launched, it had a UICoder/CodedUI tests feature, but no support for Silverlight application. Therefore, we could not make use of its abilities for automating testing for one of the latest Microsoft technologies. MS eventually came out with a CTP version of a Silverlight Plugin, which when installed with the IE, made it possible to record and playback actions (Every step in a coded UI test is an action that first needs to be recorded; the playback is the actual run of the test that inspects conditions on a pass/fail basis) for the Silverlight framework. Even so, this was not enough considering that the greatness of UICoder was attributed to how it mapped and stored the individual controls which could be later accessed through code, or the "CodedUIBuilder", to place assertions. (conditions or pass/fail criterion) For a Winforms or ASP application this was done easily by UICoder, but in the case of Silverlight framework it failed to recognize individual controls. In other words, it needed to be told specifically which control was to be seen and recognized, and by which name. The Present As of now, MS has already released the Feature Pack2 for VS2010, which incorporates the support for recording and playing back CodedUITests for Silverlight Applications. Nevertheless, we still need to manually generate/code the AID (AutomationID) for individual controls in the Silverlight applications. Such applications are easier to manage with less configurations necessary to be enforced on the plugin. There are a few negative aspects to this current plugin though; it is slower, for example, than the older CTP version released. Imagine the odds of that! There are a few, better practices that we always need to follow with this version. When we are getting such features and ease to automate, some rules don't hurt that much. The Battle Creating a Silverlight application is simple enough, now that we have had such a long exposure to this technology. Once that is done we need to add a “Test Project” to the same solution, remove any Unit Tests added by default to the project, and add a new “CodedUITest” to it.Man and the Arms Starting with a very simple sample application, we can move on to complex scenarios as time moves on. For starters, lets create a Silverlight 4.0 application in VS2010. Drop an MSTextbox control and a ComponentOne RichText Box control on the Xaml page. Save and run the application. In this moment in time we can move to create/update the AID to the individual elements of the SilverLight application. We can add those manually to each element, using the “AutomationProperties.AutomationId” property for the control in XAML, or we can use tools provided with the CTP version to automatically generate them. (Attached :- AIDGenerator.zip) Using the “UpdateAID” tool before we can update the AID’s for the control, it is important to mark/identifiy the controls (which should have the AutomationId set for them). This is done by compiling the project/silverlight application through command prompt, msbuild /t:UpdateUid (assuming that we are building a C# silverlight application) This creates an XAML directive "x"Uid" with a unique Uid for every XAML control. Next we need to run the UpdateAID tool using the following instructions: 1) Open the command prompt 2) Navigate to the location where you have extracted this tool 3) Type the following Command at the prompt, labeled “UpdateAid ” After the above two steps are followed the Xaml should look like the following for a control placed on the page, ” Once the former steps are completed we are ready for the final step, recording the scripts and thus creating CodedUITests for SilverLight applications.

The War - Over and Won

Before we start with recording the scripts, we need to add a reference to the “SilverLight UIAutomation” helper (installed with the FP2 for VS2010) to the SilverLight application project. The steps below will tell you how to accomplish the task above.
Right click on the SilverLight Projects, Select the "Add Reference" option from the context menu, Select the "Browse" tab and Navigate to the following location on the local drive, "C:\Program Files (x86)\Common Files\microsoft shared\VSTT\10.0\UITestExtensionPackages\SilverlightUIAutomationHelper\" for a 64 bit machine and "C:\Program Files\Common Files\microsoft shared\VSTT\10.0\UITestExtensionPackages\SilverlightUIAutomationHelper\" For a 32 bit machine select and add the "Microsoft.VisualStudio.TestTools.UITest.Extension.SilverlightUIAutomationHelper.dll" as a reference to the project. Now we are ready to begin the script recording process. To record the scripts, follow the steps below, open the CodedUITest file we added earlier in the TestProject, rename the test method to a more recognizable name, and record the CodedUI script using the “CodedUI Test Builder”.

MESCIUS inc.