Quickly run Unit Test With VS 2012/2013/..

With VS 2012 and newer versions we can run Unit Tests from various frameworks directly from Visual Studio IDE, thanks to the concept of Test Adapters. When you are doing Test Driven Development you usually go with Red/Green/Refactor workflow; what you need is a way to quickly run all or part of your unit tests after you modified the code. The quickest solution is using the option to Run Tests After Build but it is available only for Premium and Ultimate edition, but you can also run test with little manual intervention resorting to Keyboard Shortcut.

Simply go to TOOLS->Customize menu, then choose to customize keyboard.


Figure 1: Keyboard customization in Visual Studio

Once configuration window is opened, search for TestExplorer.RunAllTests command, place cursor in the “Press shortcut keys:” textbox and press a shortcut, then press “assign” button to assign to this command. In my standard configuration I like to have CTRL+SHIFT+ALT+A shortcut, because it is not assigned to any other command and it is easy to press with left hand.


Figure 2: Assign CTRL+SHIFT+ALT+A to TestExplorer.RunAllTests command

Now I can write code, use shortcut and VS will build solution and run test for me automatically, without leaving my hands from the keyboard. Thanks to the various test adapter and the various grouping and filtering possibility offered by Test Explorer, you can do TDD in Visual Studio without the need of third party tools.

Gian Maria.

Nunit test not found for some assemblies with Visual Studio Test Runner

I’ve a project in Visual Studio 2013 where one of the assembly containing Tests refuses to show tests in Test Explorer window. The solution has tests written both in Nunit and in MSpec, and everything is good except for that specific assembly. If you notice that Test Explorer window misses some tests, the first thing you need to check is the output windows, where you can find some output for Test Adapters.


Figure 1: Output for test adapters can be found in standard Output Window

In the above situation the assembly that is ignored is Intranet.Tests.dll and the reason is that it is built for Framework45 and x64 platform, while the test runner is executing against x86 platform. Everything seems ok, every project is compiled in .ANY CPU, but looking at the raw project file I can confirm that PlatformTarget is set in x64. Changing to x86 (or removing it completely) solves the problem.


Figure 2: Platform target changed from x64 to x86

After I changed the PlatformTarget attribute, all tests belonging to that assembly are now available Test Explorer window.

Gian Maria.

Programmatically use of Coded UI in Visual Studio

Coded UI Tests are a specific type of UI testing introduced with Visual Studio 2010. You can create your first Coded UI test following simple instruction from MSDN documentation. Most of the introductory examples shows you how you can use the Recorder tools to record interaction with a software (Web, WinForm, Wpf. etc) to generate what is called a UiMap. An UiMap is nothing more than a big Xml files where the recorder records the interaction with the UI and a bunch of automatic generated classes to interact with the UI.

Using a UiMap is probably not the best option for large projects, because the cost of maintaining it could become really high. This is usually not a big problem, because UiMap is used to generate code based on a set of classes belonging to Visual Studio Testing Framework that makes possible to interact with a UI from code. If maintaining a UiMap is difficult for you you can directly use these classes in your test. To show you the “hello world” equivalent of CUIT, here is the code needed to open a page in a browser and click an hyperlink.

using ( BrowserWindow browserWindow =
                new System.Uri("http://tailspintoys.azurewebsites.net/")
    HtmlHyperlink link = new HtmlHyperlink(browserWindow);
            "Model Airplanes"

The code is really simply, you must use the BrowserWindow.Launch static method to create an instance of BrowserWindow class pointing to a given Url. The BrowserWindow class is a wrapper defined Visual Studio Coded Ui assemby used to abstract the interaction with a web browser. The next step is locating the hyperlink you want to click, operation that can be accomplished with the HtmlHyperlink object. This object derives from the UiTestControl base class, and abstracts the concept of a control in the User Interface. The constructor of HtmlHyperlink object needs an instance of a containing control, in this example the whole browserWindows object. The need for the Container is having a root control that will be searched for the control.

To specify the exact Hyperlink control you want to interact with, you should populate SearchProperties collection, specifying the criteria you want to use. In this example I used the InnerText property, but you can use a lot of other criteria. Thanks to PropertyNames static collection of HtmlHyperlink object you can enumerate all the properties that can be used to locate the control. Inner Text is not usually the best option, using unique Id is usually a better approach, but the key concept is: You should use the criteria that is most stable in your scenario/environment. If you can ask to development team to assign unique id or unique names to each control, tests will be more robust and quicker.

Once SearchProperties collection is filled with critera, you can interact with the control, accessing properties or passing it to Mouse.Click method to simulate a click. CodedUI engine will locate the control on the page only when You will access properties or pass the control to some method that interact with it. This is really important, until you do not access properties the engine will not try to locate the control on the UI.

Remember to enclose the BrowserWindow object in a using block, this will ensure that the instance of the browser opened during the test will be always closed. This prevents multiple browser windows to remain opened after the test if some exception occurred.

Gian Maria.

Is it possible to run Coded Ui Test in a Virtual Machine instead that in my primary machine?

Code UI Test are an effective way to test your UI through automation, they absolutely are not a substitution for Unit Testing, but they can be used effectively to verify the whole application behave as expected. The most annoying part of Coded UI Test is that while they are running you cannot do anything else on the computer, because mouse and UI are used to run the test. This lead to a very common question

Is it possible to run Coded Ui Test in a Virtual Machine instead that in my primary machine?

The answer is yes, and it is a really simple task to accomplish. First of all install a Test controller on a machine in your network (or a virtual machine if you want to run test inside a local VM) and configure it.


Figure 1: Configure user used to run the service and nothing more 

You need only to specify the account used, and you should not register it to a Team Project Collection, just leave any other option blank. Then you need to install Test Agent on the same machine or to another one, and configure that test agent to connect to the previous installed test controller.


Figure 2: Configure the agent to log on automatically and connect to the test controller

Now you should see that the Agent component connects to the controller and the Test Agent Status is online


Figure 3: The test agent is online and connected to the controller.

It is time to go back to Visual Studio, right-click on the solution name and add new item, from the list of templates choose Test Settings


Figure 4: Add a test settings to the solution

Even if in VS 2012 test settings are not used by default as in VS2010 they are still there. In VS 2012 you do not usually need a Test Settings file, unless you want to run tests with some non standard configuration, as in this example. Once you have added a Test Settings file you can edit it and choose to execute test remotely specifying the name of the machine that has the Test Controller installed.


Figure 5: Choose to run test with Remote Execution

Now you should simply save the file, and choose as the active test settings browsing for the file


Figure 6: Activate test settings

Now if you run again the Coded UI Test it will be run in the machine with the test agent.


Figure 7: The VM with test agent runs tests for me

Thanks to this configuration you can execute any Unit Test in a remote machine, not only CUIT.

Gian Maria.

Code coverage during TFS 2012 build

A common question about TFS 2012 build is: how can I ask for code coverage?

The answer is really simple, you should go to the test section of build definition and change the run settings from Default to another setting that includes code coverage and this is really everything you need to do.


Figure 1: Change run settings to enable code coverage

Now launch the build and verify that you have your binaries instrumented and Code Coverage correctly computed.


Usually this lead to another question: Can I decide which assembly to include in code coverage instead of having all of them instrumented?

The solution to this answer is creating a customized test run setting file, the only drawback is that you have no template inside Visual Studio and no editor (as you had in VS 2010 with TestSettings files). The good news is that you can simply add an xml file inside your solution, give to it the extension .runsettings and copy inside it this simple fragment of configuration.

<?xml version="1.0" encoding="utf-8"?>
<!-- File name extension must be .runsettings -->
      <DataCollector friendlyName="Code Coverage" uri="datacollector://Microsoft/CodeCoverage/2.0" assemblyQualifiedName="Microsoft.VisualStudio.Coverage.DynamicCoverageDataCollector, Microsoft.VisualStudio.TraceCollector, Version=, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a">
            <!-- Match assembly file paths: -->


            <!-- We recommend you do not change the following values: -->


You have lots of options, but in this example I’m interested only in limiting the number of assemblies that will be instrumented for Code Coverage. This can be done simply specifying one or more regular expression in the ModulePaths section. You can use Include to define regex for inclusion, or you can use exclude to specify which assemblies will be excluded.

Once you authored this file, you should use it as active test setting configuration to test if everything is good, and verify that after running all of your test locally, Code Coverage result is what you expected. Remember that once you’ve have this run settings activated, it will be used for all of your local test run.


Once everything is ok you need to store this file in source control, check-in and modify Build configuration to use this customized file as a Run Settings File for the build and the game is done.


Now fire the build again, this time only selected assemblies will be used for code coverage.


MSDN Link to test run setting file: Customizing Code Coverage Analysis

Gian Maria.