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

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 (
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,

<TextBox x:Uid="textBox1" Height="37" HorizontalAlignment="Left" Margin="21,16,0,0" Name="textBox1" VerticalAlignment="Top" Width="148" AutomationProperties.AutomationId="textBox1" />”

Once the former steps are completed we are ready for the final step,
recording the scripts and thus creating CodedUITests for SilverLight

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,
Files (x86)\Common Files\microsoft
for a 64 bit machine and

Files\Common Files\microsoft

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”.

Record some actions in the RichTextBox, apply some formatting, and generate the code.

Play back the scripts to see the actions getting played back, and don't forget to enjoy the experience!

Ready Reckoners:
For more help, you can always visit the following links:

Vishnu’s Blog on MSDN
UI Automation in Silverlight - Part II (The Easy Way)

MSDN Command Line Interface