During one hour and 30 minutes I managed to give a brief introduction to the product features of the upcoming release of Visual Studio 2010. In the first part I covered some slides and did a live basic installation of TFS2010 on Windows 7. In the second part I demoed some of the cool features of Visual Studio 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.

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.

With my new company Sparkles I don’t only provide ALM consultancy services, but I also try to setup advanced training courses in Belgium with local and international experts.

An exclusive partnership with IDesign is set up to bring the best training to Belgium. IDesign’s training courses are among the world’s most intensive, most comprehensive .NET training classes given by the IDesign architects who have a world-renowned reputation as industry leaders. The IDesign architects are all frequent speakers at major international software development conferences, where they present their techniques, ideas, tools and breakthroughs.

On May 3-4, 2010, I will also deliver for the first time a detailed training on the new Application Lifecycle Management features of Visual Studio 2010. The Training class is called ALM with Visual Studio 2010.

This year Microsoft Techdays in Belgium are scheduled on March 30-31 + April 1 and I’m confirmed as a speaker. I will deliver a session on Branching and Merging with Team Foundation Server 2010.

In January I’m also starting to setup Team Foundation Server 2010 (Beta 2) at 2 new clients. More and more small development shops also see the benefits of a fully integrated development platform. Those companies that were still in doubt a few years ago are now convinced because of the promising upcoming release of Visual Studio 2010. The ALM train is on the rails! Very busy, but exciting times!