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 reﬂ 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 Uniﬁ 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.
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 unﬁ nished code in
the repository without actually checking it in. It also provides different types of locks when
checking out ﬁ 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 deﬁ 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 deﬁ 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.