Desktop Developer

Enhance VSTS Development

Check out these tips to help simplify and enhance your development with Visual Studio Team System and Team Foundation Server.

• By Benjamin Day and Richard Hale Shaw
• 11/01/2006

Microsoft's Visual Studio Team System (VSTS) represents an enormous undertaking from Microsoft. Taken as a whole, the various editions of VSTS comprise an ambitious attempt at capturing a significant share of the ALM market with specialized team management software intended to help enterprises integrate more efficiently and more effectively.

In this article, we'll walk you through some specific tips and tricks for getting the most out of VSTS. Specifically, we'll show you how to use VSTS for deploying supporting files as part of your VSTS unit tests; how to streamline TFS permissions management; and how to customize the "bug" work item template. Together, these tips will save you time and effort, while illustrating how to take better advantage of the many services VSTS offers.

Let's start by taking a look at deployment. App.config isn't the only place to keep configuration values: Some third-party tools, such as NHibernate, have their own configuration files (hibernate.cfg.xml). So, when you write tests for code that uses these tools, these files need to be in the bin directory when you run your VSTS unit tests. Sounds easy, doesn't it? Simply set up a post-build event that copies any additional files into "bin\Debug" and you're good to go, right?

Well, not so fast. If you're using VSTS for creating and managing unit tests, you'll find that it does things a little differently. The reason? With VSTS, you're not just operating by yourself: You're creating materials that can be shared with the rest of your team. Further, each time you run a test fixture (TestClass), VSTS creates a new directory containing fresh copies of your unit test binaries. This complicates moving configuration files in a post-build event because you don't know what the name of that directory is going to be. VSTS is smart enough to move your app.config to the right place—but it ignores any other files.

You have two options for addressing this issue: Use the DeploymentItem attribute or modify the test run configuration.

The DeploymentItem attribute allows you to specify a file that should be copied before you run your TestMethod:

[TestMethod()]
[DeploymentItem("MyConfigFile.xml")]
public void FileExistsTest()
{
	FileReader target = new FileReader();

	Assert.IsTrue(target.FileExists(),
		"Could not find config file ({0}).",
		target.GetConfigurationPath());
}

The DeploymentItem attribute does have a major drawback however: It's allowed only on methods—not classes. This might be fine if your configuration file is required on only a few test methods, but it quickly becomes impractical if you're using the configuration file with every test in a fixture or every test in a test assembly.

If you need to use your configuration file in a lot of tests, a better solution is to modify the test run configuration file. VSTS creates a test run config file whenever you create a VSTS Test Project, stores it in your Solution's Solution Items folder, and names it "localtestrun.testrunconfig."

You can modify the test run config file by double-clicking on it to bring up the test run configuration editor, then clicking on Deployment. Click on the Add File and Add Directory buttons in the resultant dialog to select files and directories to deploy with each test run, as opposed to an individual test (see Figure 1).

Streamline Permissions Management
Team Foundation Server (TFS), like other server applications, requires that you grant specific permissions to new users (such as new Team Project users). Unfortunately, with TFS, this means granting permissions for the Team Project itself, the project's SharePoint Portal, and its SQL Server Reporting Services site. Plus, TFS doesn't give you a unified, easy way to do it. A good way to handle this problem is to use a Windows User Group to manage permissions across all three pieces at once. Instead of granting permissions directly to each user, you assign permissions to the Group. This enables you to grant access to the project simply by adding the new user to the Group.

Create the Windows User Group on your domain or on your TFS machine (call it "TFS Users"), and take these steps to grant permissions to the Group. First open Visual Studio and connect to TFS using Team Explorer. Next, add the Group to your Team Project, and right-click on your Team Project. Now select Team Foundation Server Settings and then Group Membership. You should now see the Project Groups dialog.

Now select the Contributors group and click on the Properties button to edit the members of this group. Then select the Windows User or Group radio button and click on Add. Use the Windows dialogs to select "TFS Users." When you're finished choosing the group, you should see it appear on the Members tab. Click on OK to exit this dialog. The group now has permissions to access the project though Team Explorer.

The next step is to set up permissions for the Group in the Team Project's SharePoint site. In the Team Project's Project Groups dialog, you need to click on the Windows SharePoint Services Site Administration link. When the SharePoint top-level Site Administration page appears, click on the Manage Users link. Now click on the Add Users button from the Manage Users page. On the Add Users screen, type the fully qualified name of the Group in the Users box (such as "Domain Name\TFS Users"). Under Choose Site Groups, select Reader.

Click on Next and then Finish to save these permissions, and then assign permissions for the Group in the Team Project's SQL Server Reporting Services site. From the Team Project's Project Groups dialog, click on the SQL Server Reporting Services link to get to the SQL Server Reporting Services administrator. Next, click on your project name, select the Properties tab, and then click on the Security link in the left bar to navigate to the security editor for your project.

You're nearly finished. Click on the Edit Item Security button, which brings up a message box asking if you want to override settings from the parent item; click on OK. Then click on the New Role Assignment button and type the fully qualified name of the TFS Users group into the "Group or user name" box and check the Browser and Report Builder checkboxes. The Browser role lets you view a TFS report and the Report Builder role lets you modify the report definition and the report parameters (see Figure 2). Click on OK to save these permissions.

That's about it. You've set up centralized permissions administration for TFS. Now all you have to do is start adding users to the Group. Note that you might notice a delay of a few minutes between the time you add a user to the Group and when the user becomes available in a work item's "Assigned to" list. Updating this list is one of the operations that TFS does on a schedule. If you're feeling impatient, you can force this list to refresh by recycling the IIS process on the TFS machine.

Customize the "Bug" Template
In an ideal world, developers dutifully change Bug Work Items in Team Foundation Server (TFS) projects from Active to Resolved to Closed, when appropriate, and in that order. Guess what: We don't live in an ideal world.

If a user can access a Bug Work Item in a TFS project, he or she can change its status to and from any of the three default states at any time; there's no rule that says you can't change the status of a bug from Active to Closed without changing the status to Resolved first. This might be flexible (or "agile"), but it can wreak havoc on your testing process.

An Active bug should be assigned to a developer, who then sets it to Resolved after fixing it. Then a tester (or QA person) can check it and decide if it's been fixed as asserted, in which case he or she can set it to Closed. If not, the bug can go back to Active. The point: Only testers should have the power to determine if a bug has been fixed and Closed.

In TFS terms, a Bug Work Item's status change is known as a state transition. Each Work Item can be customized to specify the security authorization associated with state transitions. In other words, by customizing the work item template for a bug, you can specify that only Testers can change the status to Closed.

To do this, you first need to differentiate one kind of user from another by creating a TFS user group called "Testers." If a user is in this group, the user falls into the "Tester" role on your Team Project.

Start by opening Visual Studio and connecting to TFS using Team Explorer. Then right-click on your Team Project, select Team Foundation Server Settings, and then select Group Membership. You should now see the Project Groups dialog.

Next, click on the New button to pop up the Create New Team Foundation Server Group dialog. In the "Group name" box, type "Testers" and click on OK. You've now created the Testers user group.

Work item templates are basically XML, so you can edit them by hand. That said, it's a lot nicer to edit them using the Process Template Editor (PTE) that's available for download from GoDotNet (see Resources). The PTE gives you a clean UI for editing the templates. It also handles loading and saving templates to and from TFS. Run the PTE, type in the name of your Team Foundation Server, and press Connect. From the Work Item Types menu, select "Open from Server," then "Bug," and click on OK.

You should now see the "Work Item Type Definition: Bug" page (see Figure 3). Click on the workflow tab and note that all the available states for a Bug appear at the top, and the list of transitions appears at the bottom. Click on the Resolved-to-Closed transition and click on the Open button.

When you first open this dialog, the For field is blank. This means that this state transition is unrestricted and available to anyone. Type "[Project]\Testers" in the For box and click on OK. Repeat this process for the Active-to-Closed transition.

The keyword "[Project]" is a placeholder for the name of the project. This allows TFS to ignore the specific name of your project when doing security and also helps you reuse your work item customizations across Team Projects. After you finish editing the transitions, click on Save on the "Work Item Type Definition: Bug" screen to upload your changes to the server.

That's about it: Now bugs can be Closed only by users in the Testers group.