Working with Microsoft® Visual Studio® 2005 Team System

130 Part II: Team System for the Entire Team

Figure 6-4 Naming the instance

You can now use the Object Test Bench to call any of the methods on the class. In Figure 6-5,

you can see how easy it is to graphically call the Bark method on the Beagle class. Prior to

the Bark method actually being invoked, you get the option to specify any input parameters

that are necessary. In the case in Figure 6-5, there are no parameters, so the Bark method can

execute without additional information. The return value can then be saved as a value in the

Object Test Bench so that it can be used later, possibly as an input to another method call.

Figure 6-5 Using the Object Test Bench to implement methods

The Class Designer also allows you to do a fair amount of refactoring directly inside the

graphical interface. For instance, back in Figure 6-3, there was an inheritance hierarchy

with a Dog class. If you wanted to extract an interface from the Dog class, you would simply

right-click the Dog element, choose Refactor, and then select Extract Interface. A wizard then

walks you through a few steps, allowing you to select which elements of the Dog class you

want to be included in the interface. The interface is then created in code, and your Dog

class is changed to refl ect an implementation of the created interface.

There are a few other things to mention about the Class Designer. As noted previously, it’s a

part of Microsoft Visual Studio 2005 Standard Edition, not just Team System, so many people

will have access to it. In addition, it’s not a Unifi ed Modeling Language (UML) diagram tool.

The Class Diagram uses a very easy to learn and convenient graphical representation of code

that helps maximize the development speed and quality of class code.

Version Control

Any development project that involves more than just creating some simple demo code has

a critical need for some sort of version control. In the Microsoft world, this has generally

meant using Microsoft Visual SourceSafe® (VSS). Although VSS was a very useful tool, many

enterprise customers chose to use a third-party version-control system instead. Many of

these tools allowed developers to use more advanced features than were available in VSS.

Chapter 6: Developers 131

With the introduction of Microsoft Visual Studio 2005 Team Foundation Server and Team

System, Microsoft has provided an advanced, full-featured, enterprise version-control

system that is able to handle the most complex development tasks. It handles tasks such

as code branching and merging with far more reliability than VSS did. It also includes new

features such as code shelving, which allows developers to place their unfi nished code in

the repository without actually checking it in. It also provides different types of locks when

checking out fi les from version control. You can decide to not lock the code at all, allow

others to check out code but not check in code, or lock other developers from even checking

out the code at all. (See Figure 6-6.)

Figure 6-6 Checking out code

One of the major features of Team Foundation Server and Team System is that it allows the

creation of version-control check-in policies. These policies can warn developers if they are

trying to check in code that violates some stated policy. These policies can be defi ned by an

administrator and include rules such as the following:

■ The source code must have been reviewed by a senior developer.

■ Unit tests must have covered more than 80 percent of the code.

■ There are no violations of the corporate naming convention guidelines.

Associating Check-Ins with Work Items

When you check in code, it can be associated with a work item. This allows developers to

track their work as it relates to their assigned tasks. When code is related to a check-in, it’s

also reported to the Team Foundation Server. This system allows reports to be generated

that track code churn, bugs, and the progress made toward project completion.

You can even defi ne a check-in policy to ensure that every piece of code added to the

version-control system is tied to a particular work item. This best practice ensures that

project managers, architects, and other stakeholders can use the built-in reports to

understand the progress being made in the various areas of the project.