Team System

Managed Code Analysis and Code Complexity

One of the coolest features of the Developer edition of Team System is integrated code analysis. That's a fancy way of saying that Microsoft has fully integrated FxCop into the IDE and build process. You can even establish checkin policies that require code analysis.

To get an idea of what's available on the code analysis "menu", I highly recommend paging through Microsoft's Code Analysis for Managed Code Warnings on MSDN:

• Design Warnings
  proper library design as specified by the .NET Framework Design Guidelines
• Globalization Warnings
  world-ready libraries and applications
• Interoperability Warnings
  interacting with COM clients
• Maintainability Warnings
  library and application maintenance
• Naming Warnings
  adherence to the naming conventions of the .NET Framework Design Guidelines
• Performance Warnings
  high performance libraries and applications
• Reliability Warnings
  library and application reliability, such as correct memory and thread usage
• Security Warnings
  safer libraries and applications
• Usage Warnings
  proper usage of the .NET Framework

Here's why it's a good idea to read through these at least once. One of the real analysis gems is hidden in there under the Maintainability category -- rule CA1502: Avoid excessive compexity.



The documentation page for the rule confirms this is a warning based on cyclomatic complexity, a classic computer science measure of function complexity. Unfortunately, the limits are hard-coded, which is too bad:

25	Warning
50	Critical Warning
75	Error
100	Critical Error

That's awfully generous, considering that some people consider anything with a cyclomatic complexity over 40 a complete failure!

Requiring a "clean build" prior to check-in

Another question that came up during our Team System migration was

How do we require developers to only check in code that compiles?

This is a perfectly reasonable request, since checking in code that doesn't compile would be pathological. But I'm sure you know your share of pathological developers, too..

At first glance, the existing check-in policies don't appear to work. Is it time to create a new check-in policy? Not so fast! It is possible to require a clean build prior to check in using the built-in policies, but it's not exactly intuitive.

All you need to do, as it turns out, is add the Code Analysis check-in policy:



You don't have to actually do any code analysis; you can de-select all the code analysis rules if you want. Just make sure you select "Enforce Code Analysis for Managed Code".



Once you enable this rule and attempt to check in non-compilable code, you'll get the expected "Hey, genius, you can only check in code that compiles" check-in policy warning:



That's because code analysis requires a clean build to work its magic.

(with thanks to Erwyn Van Der Meer, who first discovered this)

Adding a new check-in policy

One question that came up during our Team System migration was

How do we require developer comments on check-in?

Surprisingly, there is no built in code check-in policy that requires developers to add a comment. But it's easy enough to create a new check-in policy with a bit of .NET code.

A boilerplate Team System Policy looks like this:

---

using System;
using System.Windows.Forms;
using Microsoft.TeamFoundation.VersionControl.Client;

[Serializable]
public class BoilerplatePolicy : PolicyBase
{
    public override string Description
    {
        get { return "describes this policy"; }
    }

    public override string InstallationInstructions
    {
        get { return "describes how to install this policy"; }
    }

    public override string Type
    {
        get { return "friendly display name of policy"; }
    }

    public override string TypeDescription
    {
        get { return "describes what this policy does"; }
    }

    public override bool Edit(IPolicyEditArgs args)
    {
        // no configuration to save
        return true;
    }

    public override PolicyFailure[] Evaluate()
    {
        if (false)
        {
            return new PolicyFailure[] {
                new PolicyFailure("describe failure", this) };
        }
        else
        {
            return new PolicyFailure[0];
        }
    }

    public override void Activate(PolicyFailure failure)
    {
        // provide some winforms UI describing how to fix the policy failure
    }

    public override void DisplayHelp(PolicyFailure failure)
    {
        // provide some winforms help UI
    }
}

---

But a boilerplate policy isn't very interesting. James Manning provided a code sample for the Check for Comments Policy, which I have packaged into a Visual Studio 2005 solution (5 kb).

Once you've compiled CheckForCommentsPolicy.dll, you need to copy it somewhere on the client PC. I copied mine to the c:\test\ folder.

Now we need to edit the registry to let Team System know there's a new policy at that location:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\VisualStudio\8.0\TeamFoundation\SourceControl\Checkin Policies]
"CheckForCommentsPolicy"="c:\\test\\CheckForCommentsPolicy.dll"

Once you've copied the .dll and edited the registry, you can now configure the new rule in Team System.

Right-click your project in Team Explorer, then select Team Project Settings, Source Control:

From here, add a new policy on the Check-in Policy tab:

Notice our new check for comments policy appears and can be selected.

Download the Visual Studio 2005 solution (5 kb) containing the CheckForComments policy and try it yourself. Or maybe you want a policy that checks files with regular expression patterns?

Switching between Team System and SourceSafe

During our migration period, we are currently using both Visual SourceSafe 2005 and Team System for source control.

You can switch Visual Studio source control providers "on the fly" via the Tools, Options, Source Control, Plug-in Selection dialog:



And if you're like me, you keep forgetting to switch back, and wondering "Gee, why aren't my Team System source control menus appearing?" Doh!

A Visual Tour of the Team Editions: Team Suite

I've completed my visual tour of the Visual Studio Team System Editions:

• A Visual Tour of the Team Editions: Developer
• A Visual Tour of the Team Editions: Tester
• A Visual Tour of the Team Editions: Architect

It's a helpful way to visually see what you're getting in each role-specific edition:

I'm a Developer	I'm an Architect	I'm a Tester

If you don't want to choose-- or be limited to-- a specific role, you want Team Suite, which includes the features of all three role editions.

Here's what the Team Suite about dialog looks like.



As promised, each of the three role-specific editions show up in the installed products list box.

And here's the difference between Team Suite and Visual Studio 2005 Pro in the advanced setup options:



The top "enterprise" section (?) corresponds to Architect, while the Developer and Test additions are called out by name.

A Visual Tour of the Team Editions: Architect

There are four "editions" of Team System, which I talked about in Comparing Visual Studio Team System Editions.

It can be a little confusing to distinguish exactly what is different between the Team Editions-- much less the difference over "plain old" Visual Studio 2005 Professional! So here's a visual tour of what Team Edition for Software Architects offers you.

First, the thrilling about dialog:



The only new item in the Visual Studio 2005 setup process is the Enterprise Tools checkbox:



Architect edition is all about the diagrams. You can add a new diagram to a solution via the File, Add, New Distributed System Diagram menu:



The same New Distributed System Diagram menu item is available via the right-click menu in the solution, and also on the Project menu:



The File, New Project menu also sports a new Distributed System Solution project type:



So what exactly are these diagrams? Here's a visual sample of each one.

Logical Datacenter Diagram:



System Diagram:



Application Diagram:



Note that the only solution diagram can be converted into Visual Studio project files automatically. The other two diagrams can be converted into deployment summary diagrams and HTML.

Simple Profiling with Team Developer

Team System Developer Edition (and, of course, Team Suite) includes integrated application profiling. Profiling is just a fancy way of saying "performance analysis".

If you've ever wondered..

1. What parts of my code are slow?
2. How much memory is my program using?

.. then profiling is for you.

Here's a little program I whipped up that concatenates strings two different ways. We'll try simple concatenation using the plus (+) operator, then try with a StringBuilder.

---

class Program
{
    private static string _text = "The quick brown fox jumps over the lazy dog ";
    private static int _iterations = 5000;

    static void Main(string[] args)
    {
        AddStringsConcat();
        AddStringsBuilder();
    }

    static string AddStringsConcat()
    {
        string s = "";
        for (int i = 0; i < _iterations; i++)
        {
            s = s + _text;
        }
        return s;
    }

    static string AddStringsBuilder()
    {
        StringBuilder sb = new StringBuilder();
        for (int i = 0; i < _iterations; i++)
        {
            sb.Append(_text);
        }
        return sb.ToString();
    }
}

---

Okay, so this one is kind of er.. obvious, but it's a good test case for profiling.

Let's kick off the profiler via the Tools, Performance Tools, Performance Wizard menu. One of the first questions the Wizard asks is... Sampling or Instrumentation?



You almost always want to start with sampling. Instrumentation has an enormous memory and disk footprint. That said, if you are narrowly focusing on a specific bit of code, you definitely want instrumentation to isolate it.

That's the only question of consequence in the wizard. It's really short. Once you finish, you'll have a new performance project in the Performance Explorer pane on the left hand side of the IDE. Right click the project, then select "Launch" to run it:



The output is an enormously detailed multi-page report. However, the first page is a simple high level summary:



So it's pretty obvious where the problem is:

• We spent 96 percent of our execution time in the AddStringsConcat() function.
• We spent 42 percent of our execution time in the System.String.wstrcpy function.
  

Adding five thousand strings together with the plus operator is, apparently, a Really Bad Idea^tm. But wait-- it gets worse!

The default performance analysis only measures runtime. It doesn't include any information about memory footprint! Let's fix that. Right click the performance project and select Properties:



Now turn on memory profiling collection:



Click OK and re-run the performance analysis. Don't worry, our old results aren't overwritten -- a new report will be generated alongside the old one.

Here's the summary page for the new report:



Note that this is completely different than the previous summary-- it's all about memory now. And boy are we using a lot of it:

• System.String.Concat is using 995 kilobytes of memory
• We created 5,029 instances of System.String

That's pretty awful compared to the 1.4 kilobytes that the StringBuilder needed.

These high level summaries aren't just HTML, either. They're fully clickable for drill-down detail. For example, if I was curious about those 5,029 instances of System.String, I can double-click on it:



As expected, the vast majority of these allocations are a result of our incredibly naive string concatenation.

A Visual Tour of the Team Editions: Test

There are four "editions" of Team System, which I talked about in Comparing Visual Studio Team System Editions.

It can be a little confusing to distinguish exactly what is different between the Team Editions-- much less the difference over "plain old" Visual Studio 2005 Professional! So here's a visual tour of what Team Edition for Software Testers offers you.

First, the thrilling about dialog:



The only new item in the Visual Studio 2005 setup process is the Team System Test Tools checkbox:



Since this is the test edition, as you might expect, the Test Menu figures prominently:



Developer edition also has a Test menu, but it only offers a few basic tests (Ordered and Unit). Test edition offers the full palette of possible tests:

• Generic
• Load
• Ordered
• Unit
• Web

There's also a long list of test configuration opions in the Tools, Options dialog:



It may not seem like there's much in Test Edition compared to Visual Studio 2005 Pro or Standard, but the added test features are incredibly deep. Far too deep for me to present in this brief visual tour! For example, the web testing and load testing features alone are easily competitive with the standalone commercial offerings I've seen in these areas.

Importing Visual SourceSafe databases into Team System

Team System includes a dedicated utility for importing your existing Visual SourceSafe databases into Team System source control:

C:\Program Files\Microsoft Visual Studio 8\Common7\IDE\VSSConverter.exe

Eric Jarvi has a good walkthrough for using VSSConverter, but it's a little antiquated now. Let's bring it up to date with a fresh import using the release candidate.

Before we get started, a few prerequisites:

1. You must have Visual SourceSafe 2005 installed on the machine you're running VSSConverter from. Unfortunately, VSSConverter has some dependencies on DLLs in VSS 2005. You can uninstall VSS 2005 once you're done with the migration, but you must have it installed when running VSSConverter.
2. You must have SQL Express installed and enabled on the machine you're running VSSConverter from. This isn't exactly obvious from the documentation, but VSSConverter uses the local SQL instance as a scratch database during the conversion. If there's no local scratch database, the migration will bomb with cryptic SQL errors. We burned a couple hours troubleshooting this, when it turned out that SQL Express was simply disabled on the PC. Doh!
   

There are two primary commands for VSSConverter: analyze, or migrate.

VSSConverter [/?|h|help] [analyze|migrate] [settings_file]

 analyze                Analyze VSS repository
 migrate                Migrate VSS repository
 settings_file          Name of settings file
 /? , /h or /help       Display above help

Example:
  > VSSConverter analyze settings.xml .... Starts Analysis
  > VSSConverter migrate settings.xml .... Starts Migration

Instead of passing a bunch of cryptic command line switches, we pass.. a bunch of slightly-less-cryptic XML. Here's a skeleton template for the analysis settings:

<?xml version="1.0" encoding="utf-8"?>
<SourceControlConverter>
  <ConverterSpecificSetting>
    <Source name="VSS">
      <VSSDatabase name="d:\vss-test\"></VSSDatabase>
    </Source>
    <ProjectMap>
      <Project Source="$/" ></Project>
    </ProjectMap>
  </ConverterSpecificSetting>
</SourceControlConverter>

Edit this to taste and save it as analyze.xml.

Now we'll analyze the Visual SourceSafe database to make sure nothing bad will happen during the migration. We hope, anyway..

VSSConverter analyze analyze.xml

Initializing...
VSS administrator password:

Scanning $/
Scanning $/ConsoleApplication4.root
[ list of scanned files omitted ]
Analyze complete.
Analyzed 9 files and 5 folders.
Warnings 2 and Errors 0
Pre-migration report file: VSSAnalysisReport.xml

The analysis produces VSSAnalysisReport.xml:



As long as nothing catastrophic was revelaled during the analysis, we can proceed to the migration.

Like the analysis, migration settings are provided via an XML input file. Here's a skeleton template:

<?xml version="1.0" encoding="utf-8"?>
<SourceControlConverter>
  <ConverterSpecificSetting>
    <Source name="VSS">
      <VSSDatabase name="d:\vss-test\"></VSSDatabase>
      <UserMap name="UserMap.xml" />
      <!--<SQL Server=".\SQLExpress" /> -->
    </Source>
    <ProjectMap>
      <Project Source="$/" Destination="$/Demo/Main/"></Project>
    </ProjectMap>
  </ConverterSpecificSetting>
  <Settings>
    <TeamFoundationServer name="TeamSystem" port="8080" protocol="http"></TeamFoundationServer>
  </Settings>
</SourceControlConverter>

Edit this to reflect the correct values for your setup, and save the file as migrate.xml.  The analysis also produces a file, UserMap.xml, which lets you map SourceSafe users to Team System users. You'll want to edit that, too.

One caveat: the Team System destination folder you specify must be empty or the migration will complain, and abort. Luckily, if you provide a folder name that doesn't exist, it'll automatically be created for you.

Let's attempt the migration:

VSSConverter migrate migrate.xml

Initializing...
This will start migration with following inputs:

SourceSafe Folders -> Team System Folders
$/ -> $/Demo/Main
VSS Database: d:\vss-test\srcsafe.ini

Team Foundation Server: http://teamsystem:8080/
Migration Settings File: migrate.xml
Migration Report: VSSMigrationReport.xml

Depending on the VSS database size, migration may take few hours to complete.
Please verify all inputs are correct and confirm.
Start migration (Y/N)?y

VSS administrator password:
Connecting to Team Foundation Server.

Scanning $/ for migration
[ list of scanned files omitted ]

Migration complete.
Migrated 22 Actions
Warnings 2 and Errors 0
Post migration report file: VSSMigrationReport.xml

The migration produces VSSMigrationReport.xml:



Here's what the newly migrated project looks like in Source Control Explorer:



Indeed, it's identical to the Visual SourceSafe data, comments and all!



However, VSSConverter isn't magic -- it can't convert everything. If you've used branching, sharing, or pinning in Visual SourceSafe, don't expect that to convert well:

• Sharing is not supported in Team Foundation source control. Shared files are migrated by copying the version of the file at the time sharing began to a destination folder. From then on, the changes made to the shared file are replicated to both copies.

• Branching a file. Because sharing is a pre-condition of branching, the migration of a shared file results in copying the file to the destination folder. After the branch event, the changes to any branch are migrated to the respective copy in Team Foundation source control.

• Pinning is not supported in Team Foundation source control. To help you locate items in the Team Foundation source control repository that were once pinned in the SourceSafe database, the converter tool assigns a “PINNED” label to the version that was pinned

We've imported a few VSS projects into Team System now, and the main problem we've run into is with branching -- you don't get any file comments past the last branch.

Of course, in my opinion, if you use branching in VSS, you're asking for problems, but that's an entirely different story..
 

Troubleshooting Office Integration in Team System

One cool feature of Team System is the two-way integration with Microsoft Office. For example, in this task view, I can click the highlighted toolbar buttons to view the tasks in Excel or Project:



What's even cooler is that this isn't just a static read-only copy of the data. It's true two-way integration: any edits I make in the Excel or Project version can be saved back into Team System. This is done through Office add-ins that Team System installs.

However, you need to have .NET Programmability Support installed in Office, or you may get the "TF86001: Team Foundation was unable to load the Office AddIn" error:



If, like us, you didn't have this feature installed, the Team Foundation Server Readme documents how to install it:

1. In Control Panel, open Add or Remove Programs.
   
2. Make sure that Change or Remove Programs is selected.
   
3. Select Microsoft Office in the Currently installed programs list.
   
4. Click Change.
   
5. Select Add or Remove Features and then click Next.
   
6. Select Choose advanced customization of applications and then click Next.
   
7. Expand Microsoft Office Excel, select the option for .NET Programmability Support, and then click Run from My Computer.
   
8. Expand Microsoft Office Outlook, select the option for .NET Programmability Support, and then click Run from My Computer.
   
9. Expand Microsoft Office Word, select the option for .NET Programmability Support, and then click Run from My Computer.
   
10. Expand Office Tools, select the option for Microsoft Forms 2.0 .NET Programmability Support, and then click Run from My Computer.
    
11. Select the option for Smart Tag .NET Programmability Support and then click Run from My Computer.
    
12. Under Office Tools, expand Microsoft Graph, select the option for .NET Programmability Support, and then click Run from My Computer.
    
13. Click Update.
    
14. Click OK.
    
15. Select Microsoft Project in the list of programs installed and then click Change.
    
16. Select Add or Remove Features and then click Next.
    
17. Expand Microsoft Office Project for Windows, select the option for .NET Programmability Support, and then click Run from My Computer.
    
18. Click Update.
    
19. Click OK.

What's a Workspace?

Whenever you open a project that's under Team System source control, say via the File, Source Control, Open From Source Control menu..



.. you're prompted to place the retrieved files in a "Workspace":



So what exactly is a Workspace? It seems like a folder on our hard drive, but it's a little more than that, as Eric Sink explains:

CVS calls it a sandbox.  Subversion calls it a working directory.  Vault calls it a working folder.  By any of these names, a working folder is a directory hierarchy on the developer's client machine.  It contains a copy of the contents of a repository folder.  The very basic workflow of using source control involves three steps:

1. Update the working folder so that it exactly matches the latest contents of the repository.
2. Make some changes to the working folder.
3. Checkin (or commit) those changes to the repository.

The repository is the official archive of our work.  We treat our repository with great respect.  We are extremely careful about what gets checked in.  We buy backup disks and RAID arrays and air conditioners and whatever it takes to make sure our precious repository is always comfortable and happy.

In contrast, we treat our working folder with very little regard.  It exists for the purpose of being abused.  Our working folder starts out worthless, nothing more than a copy of the repository.  If it is destroyed, we have lost nothing, so we run risky experiments which endanger its life.  We attempt code changes which we are not sure will ever work.  Sometimes the contents of our working folder won't even compile, much less pass the test suite.  Sometimes our code changes turn out to be a Really Bad Idea, so we simply discard the entire working folder and get a new one.

But if our code changes turn out to be useful, things change in a very big way.  Our working folder suddenly has value.  In fact, it is quite precious.  The only copy of our most recent efforts is sitting on a crappy, laptop-grade hard disk which gets physically moved four times a day and never gets backed up.  The stress of this situation is almost intolerable.  We want to get those changes checked in to the repository as quickly as possible. 

Once we do, we breathe a sigh of relief.  Our working folder has once again become worthless, as it should be.

If you bring up the Source Control Explorer (via the View, Other Windows menu), you'll see that you're not really browsing the source tree-- you're browsing the state of your workspace. If you haven't established any workspaces, your SCE will be completely empty!



As Eric noted, a this concept goes by different names in different SCM software, but it's essentially the same thing. In Microsoft's internal Source Depot system, it's called an "enlistment".

It's entirely possible to have multiple Workspaces. For example, this might be useful when you're working on your desktop PC and a laptop; you'd have a workspace on each machine. Note that the default name for your workspace is the machine name, which reinforces this concept.

However, a workspace is designed to contain multiple team projects, so you'll typically only need one workspace. So why would you ever want multiple workspaces on the same machine? There are two examples provided in the MSDN documentation:

• You need to maintain multiple versions of the same source code
• You need to review other people's code

You can view the current state of your workspaces at any time via the File, Source Control, Workspaces menu. Here's the properties dialog for the new workspace I just created:



You can also manually map new source control folders into your workspace from here.

The Team Explorer add-in

We installed the Team System release candidate yesterday here at Vertigo. It's primarily a server change, but all the clients do have to update their Team Explorer add-in.

What's the Team Explorer add-in? It provides the core functionality of Team System:



This is otherwise known as Team Foundation. The other Team Editions (Developer, Architect, Test) offer additional functionality on top of the foundation. However, no Team Edition is required; Team Explorer is a standard Visual Studio 2005 add-in, so it even works with Visual Studio 2005 Professional or Standard.

How do you know you have Team Explorer installed? Check your about dialog:



Team Explorer also shows up as a seperate item in add/remove programs, so it can be installed and uninstalled independently of whatever version of Visual Studio you may have:



The Team Explorer install can be kicked off from the Team Foundation Server CD:



The Team Editions are functional without Team Explorer installed, but they're missing a giant chunk of functionality. The Team Explorer install is the heart of Team System.

Adding Users to a New Team System Project

One of the quirks of Team System is that user permissions must be managed in three distinct places:

• SQL Server 2005 Reporting Services
• Windows Server 2003 SharePoint Services Project Website
  
• Team System

Rob Caron recently announced that Microsoft is working on an applet that will manage the permissions in all three places for you automatically, but it has no firm ETA

 In the meantime, let's say you just created a new Team System project, and you want to grant users access to it. Here's how:

1) SQL Server 2005 Reporting Services

Use the web-based permissions interface, which is set up in the /reports folder from the web root by default:
http://localhost/reports



Click on the properties tab.



Click the New Role Assignment button




2) Windows Server 2003 Sharepoint Services Project Website

Visit the Sharepoint Services project website that Team System set up for you:
http://localhost/sites/DemoProject/




Click on Site Settings.



Click Manage Users.



All new projects start out with only one user -- the user who created the project. Add the same users here that you added in step 1.

3) Team System

Load the Team System project in the Visual Studio 2005 IDE, and right click the project node:



From the Team Project context menu, select Team Project Settings, and Group Membership.



From here you can edit the membership of the four default project groups Team System sets up for you:

• Readers
• Contributors
• Project Administrators
• Build Services

Double-click a group, or click a group and click the Properties button.



As before, the only user with permissions is the user who created the project -- and that user shows up in the Project Administrators group. All the other project groups are empty.

VSTS Load Testing Lab Setup

Here's a quick overview of setting up an isolated lab for performance testing a web application. 

Load Test Client.  This is a tester or developer workstation with Visual Studio 2005 installed.  If you want to publish results to a Team Foundation Server, you'll also need to install Team Foundation Client.  Use this box to administer the test rig, run tests, and view results.  Since you'll probably be running several long running tests from this box, you'll want to have plenty of RAM.  You could have multiple client machines, but that would involve coordination among testers because you should only run one load test at a time.

Load Test Agent Controller.  This is an unattended box since the controller runs as a service.  The controller tells the agents to start the tests and also gathers & stores the test results data.  During our tests, this machine typically was under more stress than the clients.  If possible, install the controller on its own machine.

Load Test Agent.  These are also unattended boxes since the agent runs as a service.  The agents run the actual tests against the load target.  For web tests, they send http requests and receive / decode the http responses.  You need more agent computers if you want to use more think time in your tests or want to generate more load on your web application. 

Click on the picture for a larger & more legible diagram.

Comparing nCover to Team System Code Coverage

Once you've implemented unit tests, one of the questions you might ask yourself is, how much of my code is covered by unit tests? This metric is known as code coverage.

I'll demonstrate how to obtain code coverage metrics in both nUnit and Team System, using the Account class from our original Unit Testing post.

If you're using nUnit, you'll need to obtain a seperate tool to measure code coverage. One such tool is nCover. I recommend reading through the nCover FAQ to get an idea of how it works, but in a nutshell, it's a generic instrumentation tool that counts what lines of code were executed. Note that we won't be running nCover directly against our assembly; we'll be running nCover against nUnit running the unit tests in our assembly. It's a subtle distinction which is reflected in the command line syntax:

C:\>NCover.Console.exe nunit-console.exe test.exe
NCover.Console v1.5.2 - Code Coverage Analysis for .NET - http://ncover.org
Copyright (c) 2004-2005 Peter Waldschmidt

Command: nunit-console.exe
Command Args: nunitconsoleapplication.exe
Working Directory:
Assemblies:
Coverage Xml: Coverage.Xml
Coverage Log: Coverage.Log

Waiting for profiled application to connect...
******************* Program Output *******************
NUnit version 2.2.6
Copyright (C) 2002-2003 James W. Newkirk, Michael C. Two, Alexei A. Vorontsov, 
Charlie Poole.
Copyright (C) 2000-2003 Philip Craig.
All Rights Reserved.

OS Version: Microsoft Windows NT 5.1.2600 Service Pack 2    .NET Version: 
2.0.50727.42

...N
Tests run: 2, Failures: 0, Not run: 1, Time: 0.031 seconds

Tests not run:
1) AccountTest.TransferWithInsufficientFundsAtomicity : Decide how to implement 
transaction management

***************** End Program Output *****************

The output is an XML file named Coverage.Xml by default. There's a default XSLT stylesheet, so it looks reasonable when you double-click on it and open it in a web browser:



Coverage is green; non-coverage is red. note that I have 100% test coverage of our Account class. I probably should have screened out the other classes, but you get the idea.

If you want a better, more detailed view of the nCover output, you'll need to download another client application. Jeff Key created one such app, nCover Browser. Here's what Coverage.Xml looks like when viewed in Jeff's nCover Browser:



Things are a bit easier in Team System due to the higher level of integration with the IDE.

To generate code coverage metrics for Team System unit tests, you must first enable assembly instrumentation in the test properties dialog:



Once you've enabled instrumentation, re-run the tests. You can now use the Code Coverage Results pane to browse your coverage percentage. Click the highlight button (indicated by the red arrow) to visually mark the lines of code that are covered by a unit test:



Looks like our Account class is still 100% covered by unit tests! Of course, demonstrating basic test coverage doesn't mean my unit tests work, but it's a start.

SourceForge switches to Subversion

SourceForge, the famous open-source software development project hosting site, will be switching to Subversion by March, 2006:

As we enter a new calendar year, our focus remains on further improving the quality of our service. To that end, I am pleased to announce that SourceForge.net will offer Subversion in early January 2006, initially as a beta program available to approximately 50 projects. Then, if the Subversion beta period proceeds as smoothly as we expect, we will deploy Subversion site wide by March, 2006.

Going forward we intend to support both CVS and Subversion, thereby offering the two version control systems most widely used in the Open Source community.

This is according to a SourceForge members newsletter sent out in late December. It's a huge win for Subversion, as Subversion's primary goal is to replace CVS!

Comparing nUnit to Team System Unit Testing

nUnit and Team System Unit Testing are what you might call kissing cousins. They're definitely related.. but not too closely.

Both work by tagging code with attributes at the class and method level:

nUnit Attributes	Team System Unit Test Attributes
[Category("name")] [ExpectedException("myException")] [Ignore("reason")] [Platform("name")] [SetUp] [TearDown] [Test] [TestFixture] [TextFixtureSetUp] [TextFixtureTearDown] [Explicit]	[AssemblyCleanup] [AssemblyInitialize] [ClassCleanup] [ClassInitialize] [CssIteration("name")] [CssProjectStructure("name")] [DataSource("name")] [DeploymentItem("path")] [Description("text")] [ExpectedException("myExcepton")] [HostType("type")] [Ignore] [Owner("name")] [Priority(1)] [TestClass] [TestCleanup] [TestInitialize] [TestMethod] [TestProperty("name", "value")] [Timeout(30)]

Within the test methods, you perform assertions to make sure your test passed:

nUnit Assertions	Team System Unit Test Assertions
Assert.AreEqual Assert.AreNotEqual Assert.AreNotSame Assert.AreSame Assert.Contains Assert.Fail Assert.Greater Assert.Ignore Assert.IsAssignableFrom Assert.IsEmpty Assert.IsFalse Assert.IsInstanceOfType Assert.IsNaN Assert.IsNotAssignableFrom Assert.IsNotEmpty Assert.IsNotInstanceOfType Assert.IsNotNull Assert.IsNull Assert.IsTrue Assert.Less	Assert.AreEqual Assert.AreNotEqual Assert.AreNotSame Assert.AreSame Assert.Equals Assert.Fail Assert.Inconclusive Assert.IsFalse Assert.IsInstanceOfType Assert.IsNotInstanceOfType Assert.IsNotNull Assert.IsNull Assert.IsTrue

You can already see that the two have a lot in common. Sometimes the names are even the same!

I'll illustrate the difference between the two with a code sample from the nUnit quick start page. Let's unit test this Account class:

---

public class InsufficientFundsException: ApplicationException {}

public class Account
{
    public float Balance;
    public float MinimumBalance = 10;

    public void Deposit(float amount)
      { Balance += amount; }

    public void Withdraw(float amount)
      { Balance -= amount; }

    public void TransferFunds(Account destination, float amount)
    {
        if (Balance - amount < MinimumBalance)
            throw new InsufficientFundsException();
        destination.Deposit(amount);
        Withdraw(amount);
    }    
}

---

Here are the unit tests in nUnit:

---

using System;
using NUnit.Framework;

[TestFixture]
public class AccountTest
{
    Account source;
    Account destination;

    [SetUp]
    public void Init()
    {
        source = new Account();
        source.Deposit(200f);
        destination = new Account();
        destination.Deposit(150f);
    }

    [Test]
    public void TransferFunds()
    {
        source.TransferFunds(destination, 100f);
        Assert.AreEqual(250, destination.Balance);
        Assert.AreEqual(100, source.Balance);
    }

    [Test]
    [ExpectedException(typeof(InsufficientFundsException))]
    public void TransferWithInsufficientFunds()
    {
        source.TransferFunds(destination, 300f);
    }

    [Test]
    [Ignore("Decide how to implement transaction management")]
    public void TransferWithInsufficientFundsAtomicity()
    {
        try
        {
            source.TransferFunds(destination, 300f);
        }
        catch (InsufficientFundsException ex) {}
        Assert.AreEqual(200f, source.Balance);
        Assert.AreEqual(150f, destination.Balance);
    }
}

---

You can run these nUnit tests through the nUnit command line, like so:

C:\>nunit-console test.exe
NUnit version 2.2.6
Copyright (C) 2002-2003 James W. Newkirk, Michael C. Two, Alexei A. Vorontsov,
 Charlie Poole. 
Copyright (C) 2000-2003 Philip Craig.
All Rights Reserved.

OS Version: Microsoft Windows NT 5.1.2600 Service Pack 2  .NET Version: 
2.0.50727.42

...N
Tests run: 2, Failures: 0, Not run: 1, Time: 0.016 seconds

Tests not run:
1) bank.AccountTest.TransferWithInsufficientFundsAtomicity : Decide how to implement
 transaction management

Or you can use the nUnit GUI. Just point it at the compiled assembly, and it will automatically find the classes marked with the test attributes.

When we convert these tests to Team System Unit Tests, they look quite similar-- except the attributes are named a bit differently, and the test class itself resides in a seperate project:

---

using Microsoft.VisualStudio.TestTools.UnitTesting;
using System;
using nUnitConsoleApplication;

[TestClass()]
public class AccountTest
{
    private TestContext testContextInstance;
    private static Account source;
    private static Account destination;

    public TestContext TestContext
    {
        get { return testContextInstance; }
        set { testContextInstance = value; }
    }

    [ClassInitialize()]
    public static void Init(TestContext testContext)
    {
        source = new Account();
        source.Deposit(200f);
        destination = new Account();
        destination.Deposit(150f);
    }

    [TestMethod()]
    public void TransferFunds()
    {
        source.TransferFunds(destination, 100f);
        Assert.AreEqual(250f, destination.Balance);
        Assert.AreEqual(100f, source.Balance);
    }

    [TestMethod()]
    [ExpectedException(typeof(InsufficientFundsException))]
    public void TransferWithInsufficientFunds()
    {
        source.TransferFunds(destination, 300f);
    }

    [TestMethod()]
    [Ignore]
    public void TransferWithInsufficientFundsAtomicity()
    {
        try
        {
            source.TransferFunds(destination, 300f);
        }
        catch (InsufficientFundsException ex) { }
        Assert.AreEqual(200f, source.Balance);
        Assert.AreEqual(150f, destination.Balance);
    }
}

---

One advantage of unit testing within Team System is that you don't have to leave the IDE to run the tests. You can run individual tests via the Test View window:

Or, you can run all the tests at once via the Test menu, and the output appears in the Test Results window:

A Visual Tour of the Team Editions: Developer

There are four "editions" of Team System, which I talked about in Comparing Visual Studio Team System Editions.

It can be a little confusing to distinguish exactly what is different between the Team Editions-- much less the difference over "plain old" Visual Studio 2005 Professional! So here's a visual tour of what Team Edition for Software Developers offers you.

First, the thrilling about dialog:



I've scrolled the installed products down a bit so you can see the unique bits for this install. Note that I have Team Explorer installed, which isn't a part of this install; it's an IDE plug-in you install from the Team Foundation Server CD.

The Visual Studio 2005 setup process will look awfully familiar, but you have one completely new node in the install options: Team System Developer Tools.



Post install, you'll notice a new "Run Code Analysis" item on your Build menu:



This lets you run an ad-hoc code analysis. You can also turn on code analysis as a part of your build process in the project properties, on the new Code Analysis tab:



There's also a new top-level Test menu:



And on the Tools menu, a new Performance Tools menu item:



If you want the "Visio and UML Modelling" feature promised in the feature matrix, you'll need to install "Microsoft Office Visio for Enterprise Architects", which is in the \Visio folder of the product DVD.

Once you complete the install and restart the IDE, you'll get yet another new menu item-- Project, Visio UML:



I'll be delving deeper into each of these features in later posts, but that's a general idea of what you can expect when upgrading to the Developer Team Edition.

Oh, and by the way, all of the Team Editions install just fine directly on top of Visual Studio 2005 Professional. No need to uninstall if you are upgrading.