Lately I’ve been struggling with some weird behavior during a Team Build (TFS 2008). The build executed also a set of Unit Tests which passed, but during the publication step of the test results to Team Foundation Server, the operation failed time after time.

I couldn’t find any additional information (eventlog, TFS Log, …) about the root cause of this failure, but while limiting the test methods for the test run I bumped into a test method which name consisted of 461 characters!

Apparently there’s a hard limit of 256 characters for the test method names that are published to the TFS data warehouse.

Everybody should be already familiar with Continuous Integration or should I say Continuous Building?Automatically building a development codeline after a check-in is often not immediately followed by an integration action towards a main branch. I picked up the term Continuous Building in this article of Martin Fowler.

Apart from the fact how this “build automation” should be called, there are many reasons why you should enforce this behavior on different branch types for your applications. The ultimate goal is to improve the quality of the software application and to reduce the time to release the application in production. By setting up early validation (compilation, automatic testing + other quality gates) through “build automation” you will at least be notified as soon as possible of all kinds of validation errors (= quality check) and you will have a chance to fix them before other team members will be impacted by pulling a get latest on the repository.

Automatically firing a validation build after a check-in will in the end not prevent broken builds and that’s where the Gated Check-in Build will come into play with Team Foundation Server 2010.

The Gated Check-in Build in TFS2010 will prevent broken builds by not automatically committing your pending changes to the repository, but the system will instead create a separate shelveset that will be picked up by the Gated Check-in Build. The build itself will finally decide if the pending changes need to be committed to the repository based on the applied quality gates.

The picture above describes the full process of a Gated Check-In build.

How to setup a Gated Check-in build?

The Trigger Tab in the Build Definition window has now an extra option for selecting Gated Check-in.

At the moment a check-in is attempted by a developer in the branch where the Gated Check-in build is active, the developer will be faced with a dialog box.

Cancelling this window will not kick off the build, but will also not commit your pending changes to the repository. If you really want to overrule this build with committing your changes directly to the repository, you may select the 2nd checkbox to bypass the validation build (not recommended). By default your pending changes will reside in your local workspace (first checkbox). In the situation where you immediately want to start with new changes – not relying on previous changes – it might be appropriate to uncheck the first option.

In the ideal situation, the build will complete without any validation errors and will eventually commit the changes to the repository. This will also lead to a Gated Check-in notification for the original committer via the Team Build Notification tool.

If you had previously chosen to preserve the changes locally (default), you may have noticed that the files you were working on were still checked out during the build … and in fact after a successful build these changes do not reflect the as-is situation anymore of the repository. With the above window you get the option to immediately reconcile your workspace with the up-to-date repository. So, clicking the “Reconcile …” button will give you the opportunity to select the desired files to force an undo in your local workspace and to pickup the changes that were committed by the Gated Check-in build for these files.

Another way to reconcile your workspace (if you for example ignored this window or when the build notification is way too slow) is by right-clicking the completed Gated Check-in Build in the Build Explorer and selecting the option to reconcile your workspace.

If you did not choose to preserve the changes locally, there won’t be any changes to reconcile after the Gated Check-in build, even if you forced the reconciliation.

The Gated Check-in build may also be kicked off manually where you may need to create a shelveset or where you may point to an existing shelveset.

A last thing to note is that the comment that was originally supplied to the changeset by the developer will be suffixed with the NoCICheckinComment variable (default = ***NO_CI***) to prevent that another continuous integration build will be fired after the final check-in done by the Gated Check-in build.

Summary

What meant to be a small post on the Gated Check-in feature in Team Foundation Server 2010 ended up in a more detailed explanation of how it works and how you can work with it in the Visual Studio IDE. Remember that you should setup the most appropriate build types according to your specific branches. Not all branches may need a Gated Check-in build. Only configure this for branches that should never have a broken build. A Gated Check-in build may for example validate a big merge operation from a development branch to a stable main branch.

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.

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.

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

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

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.

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.

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.

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.

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.

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.

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!

Done!

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

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.

specify test list(s) in the vsmdi file

specify test containers

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.

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

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.

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.

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!