Running Coded UI Tests (from action recordings with MTLM) in Team Builds (TFS2010)

January 21, 2010

With Visual Studio 2010 (Premium/Ultimate) we are able to create several types of automated tests. Automated tests will execute a sequence of test steps and determine whether the tests pass or fail according to expected results.

Coded UI Tests provide functional testing of the user interface and validation of user interface controls.

How to create Coded UI Tests? You could create them directly into Visual Studio, but for this blogpost I want to start from an action recording in Microsoft Test and Lab Manager (MTLM). An action recording is quite useful in manual tests that you need to run multiple times and for recycling common steps in different manual tests that contain shared steps.

I did create a simple test case with different test steps in MTLM to test some behavior on my website.

TestCaseDefinition

From MTLM I started a test run for this test case.

TestSuiteOverview

Before running the test, I do need to check the action recording to be sure to capture my actions for this test.

CreateActionRecording

The Test Runner will give a detailed overview of the recorded actions. Afterwards you will be able to replay all these stored actions in the Test Runner.

ActionRecordings 

After saving the results of this test run (all data is associated to my test case) it’s time to open Visual Studio 2010 and to create a Coded UI Test.

TestCaseAttachments

CodedUITestStart

Instead of choosing the default option to record actions I did choose to use an existing action recording after which I need to retrieve the appropriate test case to link to the associated actions.

ActionRecordingPicker

By clicking OK, Visual Studio will start generating code that will represent my actions that were recorded in Microsoft Test and Lab Manager. On top of that you are also able to add assertions on parts of the user interface in a separate Coded UI Test that you may reuse in other Coded UI Tests.

CodedUITestAssertions

Now, let’s integrate this entire UI test (MyCodedUITest) into the automated build. I created a default new build defintion where I also enabled to run the automated tests.

BuildDefinition

To run unit tests that interact with the desktop during a Team Build, we need to modify the Build Service Host properties in the Team Foundation Administration Console to run the build service as an interactive process instead of running the build service as a Windows Service.

BuildServiceHost

That’s about it. Make sure that the Build Service Host is running in the command line that will pop up after starting the BuildServiceHost. Queue the build and explore the results!

TestResults

Done!

With this post I wanted to highlight the powerful integration of (automated) testing into the upcoming Visual Studio 2010 offering.


Code Coverage results with Team Builds (TFS2008)

January 20, 2010

From Wikipedia:

Code coverage is a measure used in software testing. It describes the degree to which the source code of a program has been tested.

I won’t start the discussion what’s a good percentage for code coverage and why you should care or not, but let me just say that Code Coverage results may be very welcome while testing your applications. We all know that 100% coverage for a specific application doesn’t mean that your application is fail-proof and it won’t tell you how good your unit tests are. But it may give you a nice indication of the reach of your unit tests and those results should always be combined with other metrics of your code/tests.

Recently I noticed a strange thing when setting up unit tests (including code coverage) in Team Builds for TFS2008. To run unit tests after the compilation process in the build, you basically have two options.

  1. specify test list(s) in the vsmdi file

    option1vsmdi 

  2. specify test containers  

     option2testcontainer

 

Now the tricky part about code coverage results, considering you have a solution with unit tests where you enabled code coverage in the testrunconfig file.

testrunconfig_codecoverage

Setting up a Team Build with activating unit tests via a vsmdi file will give you the requested Code Coverage results.

buildresult_option1

On the other hand, setting up a Team Build (same solution) with enabling unit tests via a test container won’t give you the desired Code Coverage results.

buildresult_option2

Why is that?! Well, Code Coverage settings are contained in the testrunconfig file and the thing is that the vsmdi file contains a reference to this testrunconfig file (open up notepad to verify), while the test containers don’t have a link with any testrunconfig file. If you want to include a testrunconfig file to your build that will be used during the execution of the unit tests, you need to specify the RunConfigFile property in the TfsBuild.proj file so that the Code Coverage settings are picked up during the run of the unit tests.

option2_solution

Result:

option2_result


Feedback VS2010 Beta2?

November 6, 2009

So, you are playing around with VS2010/TFS2010 and you have some remarks, suggestions, bugs, … Please go the Microsoft Connect site for product feedback and bug reporting.

Today I filed a suggestion for the next release of Team Foundation Server: Build Definition History. Unfortunately it’s still not possible to view history of changes made to the Build Defintion: “Drop Location”, “Build Agent”, “Trigger”, … On the Microsoft Connect site, you can easily look up other wanted featured and vote for them … but first vote for my suggestion!

Since a few weeks, there’s also a feedback survey running on Microsoft Visual Studio 2010 and the .NET Framework 4 Beta 2. If you care about the product and want your voice heard, please take some minutes to complete this online survey!


Out-of-the-box source server indexing with TFS2010

October 27, 2009

Wow! This is great! Tonight I just wanted to find out if and how it would work …

This is what I did with Beta 2 of Visual Studio 2010 Ultimate and TFS 2010 Basic on my Win7 laptop:

  • created a new Team Project
  • added a new solution with a C# Library Project to the Team Project
  • added a default Team Build to build the C# Library Project
  • added a new solution with a C# WPF Project to the Team Project
  • referenced the library assembly (file reference to dll) into the C# WPF Project and called a method on a class in that assembly
  • set a breakpoint on that line and hit F5 to start/debug the WPF application
  • pressed F11 (Step Into) when breakpoint was hit

Guess what?! Yes, Visual Studio 2010 was immediately stepping into the source file of the C# Library Project! Sweet!

I remember that it took me some time to get this working for TFS2008!

When you create a new Build Definition with TFS2010, the Index Sources option is set to true by default and this will make sure that source indexing is part of the build.

I took a peek into the DefaultTemplate.xaml file in the BuildProcessTemplates folder and found out that the Index Sources and Publish activity is indeed completely baked in! I love it already!



Build Retention Policies in TFS2010

October 11, 2009

I noticed some interesting changes for the Build Retention Policies in TFS2010 (Beta 1):

  • possible differences between retention policy for triggered and manual builds vs private builds

    You will be able to set another retention policy on private builds: builds that are run by the enabled Gated Check-in trigger.

  • extra What to delete column

    You will be able to specify more in detail what information must be deleted when the retention policy kicks in.


MSTest.exe exited with code -2146233082 during Team Build

September 17, 2009

Recently I was faced with a failure in a Team Build caused by MSTest that crashed when firing up the Unit Tests.

MSBUILD : warning MSB6006: "MSTest.exe" exited with code -2146233082

Digging a bit deeper and running the Unit Tests manually with MSTest on the build server via the command line showed me a dialog box with the following notification:

MSTest.exe has encountered a problem and needs to close. We are sorry for the inconvenience.

Nothing more, nothing less! Hmm … Note that this behavior only surfaced after SP1 of Visual Studio 2008 and TFS 2008 was installed on the build server. Before, everything worked fine. On my local development pc (with SP1 of Visual Studio 2008) all Unit Tests run without any problems.

Let’s take a look at the eventviewer to get some extra information of what’s going wrong here …

Two interesting events were logged:

  1. .NET Runtime version 2.0.50727.3053 – Fatal Execution Engine Error (7A035E00) (80131506)
  2. Faulting application mstest.exe, version 9.0.30729.1, stamp 488f21a6, faulting module mscorwks.dll, version 2.0.50727.3053, stamp 4889dc18, debug? 0, fault address 0x001c5e00.

After searching for these errors on the web I came across some blog posts that mentioned the same Fatal Execution Engine Error but the scenario where this error occurred was totally different. It had something to do with Visual Studio disappearing unexpectedly but apparently there was a hotfix available on Microsoft Connect for this Fatal Execution Engine Error. So, with no other options at that moment I decided to go for the hotfix and see what happened.

The hotfix indeed did fix the problem, but I’m still puzzled what actually caused the problem. Strange was that certain Unit Test assemblies did run well on the build server while others even didn’t get started due to the above conditions …

[I did also log this error on the Testing forum of Visual Studio Team System]


Generating ClickOnce packages with Team Build 2008

September 7, 2009

Last week I spent way too much time on troubleshooting an issue with generating a ClickOnce package with a Team Build. Generating the package was actually not the problem, but running the application always resulted in …

Reference in the manifest does not match the identity of the downloaded assembly x

It was clear that something was wrong with the manifest, but I could not find what was keeping the application from launching. I checked and double checked the build script and the way the package was built but could not find an indication of the above error. Publishing the application from within Visual Studio 2008 seemed to work without any hitches and it was then that I noticed the following setting in the Application Tab of the Start Project in Visual Studio.

Visual Studio 2008 embeds by default a manifest inside an assembly. This means that the ClickOnce executable was using this default manifest instead of the manifest that was generated with Team Build. Switching to the other option to not generate a manifest with Visual Studio did solve the issue!

Hopefully I can save someone’s time with this blogpost!


Follow

Get every new post delivered to your Inbox.