Coded UI Testing

What is Code UI Testing, or more to the point what is the difference between Unit Tests and Coded UI Tests?

Unit Tests

  • Tests classes and methods at the API level
  • If it test a UI, it’s testing an abstraction (not quite testing the UI), UI testing has been hard
  • Testing code as you built it
  • We are testing in isolation

Coded UI Tests

  • UI testing
  • Testing a running application
  • Simulates a user’s keyboard and mouse activities
  • Test the application that’s pretty much done
  • Integration testing

Looking at the layers in your application

  • User Interface
  • Presentation (MVC/MVVM)
  • Domain Model / Service Layer
  • Repository / Data Access
  • The Relational Database (Tables, Views, Stored Procedures etc)

The Coded UI tests are only interested in the User Interface, and Unit tests deal with everything else.


Unit tests test your API’s

Coded UI Tests test your running User Interfaces

Support for Code UI

Operation Systems

  • Windows 7
  • Windows 8
  • WIndows Server 2008 R2
  • Windows Server 8

Web Applications in Internet Explorer 8, 9 and 10

Windows application

  • Windows Form 2.0 and higher
  • WPF 3.5 and higher

Dynamics CRM web client

Partially Supported

  • Windows Win32
  • Dynamics (Ax) 2012
  • MFC
  • Citrix / Terminal Services
  • SharePoint
  • Power Builder

For a complete list go to:

No Support for Code UI


  • Internet Explorer 7
  • Internet Explorer 8
  • Chrome
  • Firefox
  • Opera
  • Safari


  • Silverlight
  • Flash

Office Cleint Applications



Structure of a Coded UI Test

The Test Fixture Class

  • [CodedUI] attribute
  • Editable like any other class


  • Auto-generated XML-based “map” of your UI
  • Not editable


  • Supporting information for the test
  • Auto-generated by the recorder
  • Partial class


  • partial class
  • Customizations and extensions to the UIMap.designer.cs


Create Coded UI Tests using the recorder

Create Coded UI Tests using MTM Action Recordings

Editing and extending Coded UI tests

Setting up StyleCop

How to get StyleCop working and running in Visual Studio 2012

First download the latest StyleCop from Codeplex, and install.

If you now load up Visual Studio and create a new project, how you’ll find lots of underlined code that need attention

As you can see form above, we now need to start correcting these, most are due to lack of documentation

So once you made the changes things should look better

Now that we have got it running it is time to start to configure StyleCop, if you right click on your project you’ll find StyleCop Settings

One rule which I turn off is SA1126: PrefixCallsCorrectly, just find SA1126 on the Rules tab and uncheck the rule, like this:

You’ll need to rerun StyleCop again and you’ll find that this rule is now ignored.

Setting Up StyleCop MSBuild Integration

Next is to get StyleCop running with all builds for your project, to do this check out Setting Up StyleCop for MSBuild Integration

MSBuild integration will cause the tool to run automatically whenever the code is built, and StyleCop violations will show up alongside compiler errors in the build output.

It is possible to set up the build integration so that StyleCop violations will appear as build warnings, or as build errors if so desired.

Installing MSBuild Files

To enable build integration, first be sure to select the MSBuild option when installing the tool, as shown in the image below:

This will cause the StyleCop binaries and supporting MSBuild targets files to be installed under the {Program Files}\MSBuild\Microsoft\StyleCop folder.

Adding the Import Tag

Once the StyleCop MSBuild files are installed, the next step is to import the StyleCop targets file into your C# projects. This is done by adding an Import tag to each C# project file.

For example, to integrate StyleCop to the project SampleProject, open the project file SampleProject.csproj within your favorite text editor. Scroll down to the bottom of the file and add a new tag to import the Microsoft.StyleCop.targets file. This import tag should be added just below the import of Microsoft.CSharp.targets:

<Project DefaultTargets="Build" xmlns="">

   ...Contents Removed...

  <Import Project="$(MSBuildBinPath)\Microsoft.CSharp.targets" />

  <Import Project="$(ProgramFiles)\MSBuild\StyleCop\v4.7\StyleCop.targets" /> 

   ...Contents Removed...


Save the modified .csproj file. The next time you build this project either within Visual Studio or on the command line, StyleCop will run automatically against all of the C# source files within the project.

Build Warnings Vs Errors

By default, StyleCop violations will show up as build warnings. To turn StyleCop violations into build errors, the flag StyleCopTreatErrorsAsWarnings must be set to false. This flag can be set as an environment variable on the machine, or within the build environment command window. Setting the flag this way will cause StyleCop violations to appear as build errors automatically for all projects where StyleCop build integration is enabled.

Alternately, this flag can be set within the project file for a particular project. Open the .csproj file for your project again, and find the first PropertyGroup section within the file. Add a new tag to set the StyleCopTreatErrorsAsWarnings flag to false. For example:

<Project DefaultTargets="Build" xmlns="">
    <Configuration Condition=" '$(Configuration)' == '' ">Debug</Configuration>
    <Platform Condition=" '$(Platform)' == '' ">AnyCPU</Platform>

Team Development

The configuration described above will suffice to enable StyleCop build integration on an individual development machine. However, development teams working within a well-defined development environment can set up the build integration in a more global way, so that each developer does not have to manually install StyleCop on his machine.

To do this, copy all of the files from {Program Files}\MSBuild\Microsoft\StyleCop into a custom folder within your build environment, and check all of these files into your source control system. Next, define an environment variable within your development environment which points to the location of the StyleCop targets file. For example:

set StyleCopTargets=%enlistmentroot%\ExternalTools\StyleCop\v4.3\Microsoft.StyleCop.targets

With this configuration in place, it is simply a matter of adding the following import tag to each .csproj file within your development environment:

<Import Project="$(MSBuildBinPath)\Microsoft.CSharp.targets" />
<Import Project="$(StyleCopTargets)" />

StyleCop will automatically run each time this project is built, no matter who is building the project. There is no need for each developer to install StyleCop manually, since the StyleCop binaries are checked directly into your source control system and are centrally integrated into your build environment.

Command Line

If this is not enough for you try it from the command link

msbuild myproj.csproj /p:StyleCopTreatErrorsAsWarnings=false

Upgrading an ASP.NET MVC 3 Project to ASP.NET MVC 4


ASP.NET MVC 4 can be installed side by side with ASP.NET MVC 3 on the same computer, which gives you flexibility in choosing when to upgrade an ASP.NET MVC 3 application to ASP.NET MVC 4.

The simplest way to upgrade is to create a new ASP.NET MVC 4 project and copy all the views, controllers, code, and content files from the existing MVC 3 project to the new project and then to update the assembly references in the new project to match any non-MVC template included assembiles you are using. If you have made changes to the Web.config file in the MVC 3 project, you must also merge those changes into the Web.config file in the MVC 4 project.

To manually upgrade an existing ASP.NET MVC 3 application to version 4, do the following:

In all Web.config files in the project (there is one in the root of the project, one in the Views folder, and one in the Views folder for each area in your project), replace every instance of the following text (note: System.Web.WebPages, Version= is not found in projects created with Visual Studio 2012):

System.Web.Mvc, Version=
System.Web.WebPages, Version=
System.Web.Helpers, Version=
System.Web.WebPages.Razor, Version=

with the following corresponding text:

System.Web.Mvc, Version=
System.Web.WebPages, Version=
System.Web.Helpers, Version=
System.Web.WebPages.Razor, Version=

In the root Web.config file, update the webPages:Version element to “” and add a new PreserveLoginUrl key that has the value “true”:

  <add key="webpages:Version" value="" />
  <add key="PreserveLoginUrl" value="true" />

n Solution Explorer, right-click on the References and select Manage NuGet Packages. In the left pane, select Online\NuGet official package source, then update the following:

  • (Optional) jQuery, jQuery Validation and jQuery UI
  • (Optional) Entity Framework
  • (Optonal) Modernizr

In Solution Explorer, right-click the project name and then select Unload Project. Then right-click the name again and select Edit ProjectName.csproj.

Locate the ProjectTypeGuids element and replace {E53F8FEA-EAE0-44A6-8774-FFD645390401} with {E3E379DF-F4C6-4180-9B81-6769533ABE47}.

Save the changes, close the project (.csproj) file you were editing, right-click the project, and then select Reload Project.

If the project references any third-party libraries that are compiled using previous versions of ASP.NET MVC, open the root Web.config file and add the following three bindingRedirect elements under the configuration section:

  <!--... elements deleted for clarity ...-->
    <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
        <assemblyIdentity name="System.Web.Helpers" 
             publicKeyToken="31bf3856ad364e35" />
        <bindingRedirect oldVersion="" newVersion=""/>
        <assemblyIdentity name="System.Web.Mvc" 
             publicKeyToken="31bf3856ad364e35" />
        <bindingRedirect oldVersion="" newVersion=""/>
        <assemblyIdentity name="System.Web.WebPages" 
             publicKeyToken="31bf3856ad364e35" />
        <bindingRedirect oldVersion="" newVersion=""/>

Original article can be found at: MVC 4 release notes


Custom Activities build process

If you are like me and you create a number of Custom Build Activities for TFS you want to ensure that you keep them in a tidy place.

The best place I have found is to find the BuildProcessTemplates folder and add a new folder called CustomActivities, and in this folder place all your xaml and dll’s files that you have created.

Once you’ve created the new folders and files you’ll need to make sure the build controller know about them, click Build > Manage Build Controllers then select the properties and enter :


under the Version control path to custom assemblies.













Enhancing the Build in TFS 2012

TFS has the ability to run automatic builds on the build server, this ensures that your project and solutions build and all their dependencies are near by and functional. I’ve looked all over the internet and found various samples, but none that work with Visual Studio 2012 or in the way I wanted the versioning to work. In this post I pulled together everything I have found whist looking over the Internet, I have tried to keep the same process and names as many of the samples I have found while searching for the solution.

So what we want to do is to change the standard build process to enable us to do automatic versioning of assemblies.  To do this what we need to do is insert some steps in the process just after the source has been retrieved from TFS.  We want the workflow that goes something like this:

Get Latest –> Update AssemblyInfo files with new version –> Build the solution

We need to remember that that when team build gets the code from TFS the files are in read only mode, so we’re need to change the read only flag off, change the files, and then turn it back on.  

What we are not going to do is check the updated assembly info files back into source control.  This means all developer builds will by default have a version number of and build server builds will have an incrementing build number.  This is a useful way to know if someone has tried to deploy code built on their machine instead of code built by the server.

The version number will take the format of 

Major build (Application major version)

Minor release (Application minor release)

Date (month day) (Date of the build)

Incrementing build number (This number will change on every build)

We should end up with a format looking something like this:


Building the solution

Why do we need a solution, several reasons, we need to be able to build our custom assembly and more importantly we need to be able to edit, change the custom workflow template and then have the ability to compile the workflow to ensure it is built correctly.

1.  Open VS2012 and create a solution with two C# Class LIbrary projects in it.  One for the custom build tasks we’re going to create, and one to hold the process template we’re going to change.  I have called it CustomBuildActivities and CustomBuildProcess, I’ve opted for both standard Class Libraries, as I wanted to go over what references we need to add in order to build our workflow.









2,  Now go copy the DefaultTemplate.xaml file, which you should find in the Source Control Explorer under the BuildProcessTemplates folder, rename it to something you like and include it in your project.  I have called it ExtendedBuildProcess.xaml.  Once it’s included in the solution change the Build Action to XamlAppDef. 












At this point if you try compiling you’ll get a lot of missing references.

  • System.Activities
  • System.Xaml
  • System.Activities.Presentation
  • PresentationFramework
  • WindowsBase
  • System.Drawing
  • Microsoft.TeamFoundation.Common
  • Microsoft.TeamFoundation.Build.Client
  • Microsoft.TeamFoundation.VersionControl.Client
  • Microsoft.TeamFoundation.VersionControl.Common
  • Microsoft.TeamFoundation.WorkItemTracking.Client
  • %Program Files%\Microsoft Visual Studio 11.0\Common7\IDE\ReferenceAssemblies\v2.0\
  • %Program Files%\Microsoft Visual Studio 11.0\Common7\IDE\PrivateAssemblies\
  • %WinDir%\assembly\GAC_MSIL\Microsoft.TeamFoundation.TestImpact.Client\\

Quite a lot I know, but I wanted to take you though everything that is needed.

Creating our Custom Activity

The first custom activity we are going to build will be the one we use to toggles the read only flags on AssemblyInfo files.  In your CustomBuildActivities project add a new Class called SetReadOnlyFlag.  We’ll use this to toggle the read only bits for our AssemblyInfo files later on.

We’ll need to add a few references first

  • System.Activities
  • Microsoft.TeamFoundation.Build.Client
  • Microsoft.TeamFoundation.VersionControl.Client
  • System.IO


using System.Activities;
using Microsoft.TeamFoundation.Build.Client;
using Microsoft.TeamFoundation.VersionControl.Client;
using System.IO;
namespace CustomBuildActivities
 public sealed class SetReadOnlyFlag : CodeActivity
  public InArgument<string> FileMask { get; set; }
  public InArgument<bool> ReadOnlyFlagValue { get; set; }
  public InArgument<Workspace> Workspace { get; set; }
  protected override void Execute(CodeActivityContext context)
   var fileMask = context.GetValue(FileMask);
   var workspace = context.GetValue(Workspace);
   var readOnlyFlagValue = context.GetValue(ReadOnlyFlagValue);
   foreach (var folder in workspace.Folders)
    foreach (var file in Directory.GetFiles(folder.LocalItem, fileMask, SearchOption.AllDirectories))
     var attributes = File.GetAttributes(file);
     if (readOnlyFlagValue)
      File.SetAttributes(file, attributes | FileAttributes.ReadOnly);
      File.SetAttributes(file,attributes & ~FileAttributes.ReadOnly);

This is the first Custom Activity done

Update Assembly VersionInfo Custom Activity

This Custom Activity is to change all the Version numbers to the format we are after, e.g.  3.1.1207.32454

using System;
using System.Activities;
using System.IO;
using System.Text.RegularExpressions;
using Microsoft.TeamFoundation.Build.Client;

namespace CustomBuildActivities
    public sealed class UpdateAssemblyVersionInfo : CodeActivity
        public InArgument<string> AssemblyInfoFileMask { get; set; }

        public InArgument<string> SourcesDirectory { get; set; }

        public InArgument<int> Major { get; set; }

        public InArgument<int> Minor { get; set; }

        protected override void Execute(CodeActivityContext context)
            var sourcesDirectory = context.GetValue(SourcesDirectory);
            var major = context.GetValue(Major);
            var minor = context.GetValue(Minor);
            var assemblyInfoFileMask = context.GetValue(AssemblyInfoFileMask);
            var buildDate = int.Parse(string.Format("{0}{1}", DateTime.Now.Month, DateTime.Now.Day));
            var newVersion = new Version(major, minor, buildDate);

            foreach (var file in Directory.EnumerateFiles(sourcesDirectory, assemblyInfoFileMask, SearchOption.AllDirectories))
                var text = File.ReadAllText(file);
                // we want to find 'AssemblyVersion("")' etc
                foreach (var attribute in new[] { "AssemblyVersion", "AssemblyFileVersion" })
                    var regex = new Regex(attribute + @"\(""\d+\.\d+\.\d+\.\d+""\)");
                    var match = regex.Match(text);
                    if (match.Success) text = regex.Replace(text, attribute + "(\"" + newVersion + "\")");

Okay that is the coding done, your project should build without and errors, warnings or message, perfect and clean project.

Now the fun really starts

Updating the Extended Build Process Workflow

Before we start can you make sure the project builds without an errors.





When you open your ExtendedBuildProcess.xaml on the toolbar you should find the two new CustomBuildActivites (SetReadOnlyFlag and UpdateAssemblyVersionInfo)

Now comes the tricky bit finding in the workflow where to drop the Custom Activities.  You can search the Workflow manually or use the Find option and look for “Get Workspace”, you should end up in the section of the work flow that looks something like this:












Now add a sequence activity after the get workspace activity:







Now add your two new Custom Activities to the Sequence activity, with the SetReadOnlyFlag going either side of the UpdateAssemblyVersionInfo.









Set Activity Properties

For each of the new Customer Activities we are going to have to set the required parameters






Select the Readonly Activity and then look at the properties






Before we set the properties we’ll need to set the Arguments that are coming in to the Workflow, so go to the Arguments tab at the bottom of the workflow.





Click in the Create Argument box and add a new argument called AssemblyInfoMask and give it a default value of “AssemblyInfo.*”

Create a further two arguments AssemblyMajor and AssemblyMinor setting them both to Int32 with 1 and 2 default values.


You don’t have to do this process, next but when you do it will appear in the Build process in the correct section.  Go to the metadata argument a few lines above and click the ellipsis […] button.  You will see a window appear where we can set values that will let Visual Studio know how to display this argument to the end user.  Do this for all three arguments. 












Okay now we have set the argument we can set the properties of the Activity.
















Okay that should be it.  So build the solution just to make sure everything is DONE!

Next just follow the steps to store your new custom activities and then add them in to your build process and you’re done.

I would not have been able to complete and understand this process without the help of the following two web pages. 

Customize Team Build 2010 by Ewald Hofman

How To: Versioning Builds With TFS 2010 by Richard Banks

Building to your NuGet Gallery

Build Process Meets NuGet Gallery

The next logical step is integrating your NuGet gallery with your existing build processes. If you don’t have a build process and you’re looking for a little “getting started” guidance with Team Foundation Server (TFS) build processes, check out the Microsoft Visual Studio ALM Rangers Build Customization Guide at

All right: You have a library you want to make available on a gallery, which could be the official NuGet Gallery, a proprietary gallery or even a local file share. No matter which, you’ll have to perform certain tasks to create the NuGet package, and they’re generally the same tasks no matter where the gallery resides.

Through the course of developing your product, you’ll repetitively go through the process of coding, compiling, packaging, pushing and publishing. You’ll also, we hope, include a couple of healthy doses of testing; results from that testing might make you deviate from publishing to the gallery if you find any issues


Keeping consumers happy with working software is a good thing, and you’ll have an easier time doing so using a managed process. Remember, though, the managed process can’t be entirely automated; there’s no replacement for human verification. Don’t assume you can publish just because your software passes all the automated tests. You could easily publish a package that isn’t ready and make your consumers angry. Moreover, they won’t be happy if you publish constantly and they can’t keep up with the ever-changing versions. Make publishing a conscious decision.

Use the build process to build, package and push your NuGet library to a gallery where you perform final tests and do that human verification. That way, you can choose continuous integration or a scheduled build to automatically push the package and make it ready for you to test. How might you do that? Here’s an example using TFS and its workflow-based automated build capability.

NuGet.exe is a stand-alone, parameter-driven console application, but it can easily be called by another process, such as TFS Team Build. Team Build executes a workflow; in TFS terms, this is a set of custom activities controlled through a build template and initiated by a build definition. One packaged solution for automating the NuGet development process is the NuGetter project at This project provides an automated shell around the NuGet.exe application. We’ll use this package to show what can be done and things to think about as you work toward automating your own NuGet packages.

The build definition in TFS is where you provide all the necessary information to do the packaging, push and publish. Building a flexible and repeatable build process for NuGet requires several pieces of data and the switches that turn portions of the process on or off. The data is organized into categories that are titled to give you a sense of the order in which the steps are executed.


The PrePackaging section is used for complicated or multiframework NuGet packaging that requires some initial preparation. NuGetter can call a Windows PowerShell script (if you desire) to organize the library files to make packaging easier. This step isn’t required, so you can use the flag parameter “Invoke PowerShell Script” to tell the process whether to execute the script.

You can use a .nuspec file directly to define how your package will be created or you can do so indirectly through a .csproj file. It’s up to you; use the approach that better suits your needs.

As you can see, all of the parameters required for packaging are included. Version, base path (source folder for packaging), API Key and gallery location (called Source) are all provided as part of the build definition. However, the security of this information might be of great importance to you. For example, the API Key is what allows you and only you to push NuGet packages to the gallery. If that key becomes public, anyone could push bogus packages in your name. Because of this, NuGetter allows you to provide either the actual API Key or a path to a file that contains the key. If you use a file path, the build process reads the file, extracts the key and uses it without listing the key in the log, and security is maintained. Obviously, the build service ID must have read access to the file for this to work.

Another potential issue for you is managing the version of your package. In Figure 6, the version number is provided in the build definition. But, do you really want to keep changing that number in the build definition? What happens when you have several builds (continuous integration [CI], daily, other scheduled and various manual builds)? NuGetter gives you the choice to enter the version directly or, as with the API Key, you can provide a file path that multiple build definitions can use. They will all use the same version number and you can manage it in just one place.

The Push Destination in the example is the NuGet Gallery, but this is where you provide the build destination even if you’re pushing your package to an internal gallery or to a local file store. This is another case where the build process might need to intervene. NuGet.exe expects a URL as the destination and if you’re pushing to a local store—which won’t be a URL—the process needs to interpret the destination format. In this case, instead of using NuGet.exe to do the pushing, you have the build process do it.

For reasons of completeness and feature parity with NuGet.exe, NuGetter does provide for automated publishing. Just keep in mind our earlier caveats before deciding to use this capability.

Original article

Your very own NuGet Gallery

Why Host your own NuGet Gallery? already exists as a public repository for NuGet packages, so you might question the point of hosting a gallery. That’s understandable, but what about leveraging that ecosystem infrastructure within the walls of your own dev environment? Why not set up your own private gallery not only to facilitate your product’s development ecosystem but, better yet, to tie it directly to your build and deployment processes? Moreover, anything you see at is available to you free.

Fastest and Simplest

The easiest way to host your own NuGet gallery is to expose a file share. This might sound a bit rudimentary, but if you need something fast and simple, this method works extremely well. The share can be structured as you see fit, placing your packages—that is, your *.nupkg files—anywhere on the share. You can refer to the share as a package source.

With the package source created, let’s add it to the development environment. You can have as many package sources as desired and easily move between each. To edit your package sources in Visual Studio, navigate to Tools | Options | Package Manager | Package Sources. Note that as of this writing, version 1.5 was current. You should expect slight differences across NuGet versions.

Here you can add, remove and change the default package source. If you prefer, you can do the same in WebMatrix, a free development environment. Just click on the NuGet Gallery icon on the main menu and select Add Source

As you can see, both figures list two package sources. You can choose to use just one or all at any given time.

Introducing NuGet Gallery

While the file system package source is very easy to set up and start using, it breaks down pretty quickly when you start scaling out. Luckily, NuGet.orgwas built with exactly this in mind, to provide an open platform for people to take, extend and build on for their own needs. You can find the NuGet Gallery project at The NuGet Gallery is an ASP.NET MVC 3 project built on top of Razor, OData, SQL Server and Windows Azure.

The best way to understand the features and functionality the NuGet Gallery has to offer your development ecosystem is to simply explore

Before you can create and publish a package, you need to be a registered user. Once you’ve registered, you have full rights to upload and manage your packages and edit your profile. You can also generate the unique API key that lets you automate publishing packages to the Gallery (see Figure 3). For more information about publishing a package, please see the previous article in this series, “Becoming a NuGet Author.”

When you upload a package to the NuGet Gallery, it automatically receives its own place in the Gallery

This is where you can view all of the important information about a package. For each package, the NuGet Gallery tracks the version downloads, total downloads, dates, licenses and so on. Of course, a package on the NuGet.orgsite will most likely yield considerably larger download numbers given its ecosystem, but these statistics are vital to any package author, regardless of project size.

The package feed is clearly the most important feature in the overall stack. It’s an OData feed you’ll find at http://YourGallery/api/v2. This is the same URL you’ll use as your package source. Without this feed, all of the power of NuGet is lost.

Original article