Tools for Developers

Tools for Developers

Let's now focus on the code. Team System provides many new tools specifically for developers, primarily in the areas of version control, class designing, and unit testing.

Source Control Explorer

When working on projects under version control, the Source Control Explorer window will be very important. It shows you all the projects under version control on the Team Foundation Server, based on your permission settings. (See Figure 3-19.) Source Control Explorer has many context menus, which are available with a right-click, as well as a useful toolbar that repeats all the options found by right-clicking.

Figure 3-19 Source Control Explorer

All version control functions, shown in the following list, can be performed from the explorer:

• Get Latest Version

• Get Specific Version

• Check Out

• Undo Pending Changes

• Check In

• Lock

• Unlock

• Delete

• Undelete

• Branch

• Shelve

• Merge

• Resolve Conflicts

• History

• Compare

• Label

You'll learn more about Source Control Explorer in Chapter 6.

Class Designer

The new Class Designer is another example of a Domain-Specific Language. This designer is not UML-aware, but it does specialize in the construction of .NET classes, which is what you and I both want—a tool that does one specific thing very well. Technically, the Class Designer is not part of Team System. It is part of Visual Studio 2005 Professional, but it is worth mentioning in this section.

One of the last steps that an application architect performs is to implement one or more of the ASP.NET Web services. When implemented, Visual Studio 2005 will create new ASP.NET Web Service projects and prepare the class up to the point of implementation.

NOTE
The implementation feature is available only in Visual Studio Team Edition for Architects. So, either your architect will need to begin this process, saving the projects to version control for the developers to implement, or the developers will need a copy of the Architect Edition (or Team Suite) to begin implementation themselves.

The Class Designer is a graphical tool, where each class is represented by a rectangular shape. Any properties, methods, fields, and events will be listed on the shape. (See Figure 3-20.) You can expand and collapse the member list, depending on the limitations of your monitor. You can right-click on the shape and add new members, or you can work directly in the Class Details window, which allows you to manage all class members in one easy-to-use grid.

The best part about the Class Designer is that it is tightly coupled with the source code file behind it. In other words, if you have a file named Class1.cs and its class diagram is in ClassDiagram1.cd, they will always be in sync. Changes to one file are instantly seen in the other, and vice versa. There are no reverse or roundtrip engineering steps required—another advantage of a Domain-Specific Language tool.

TIP
Sometimes it can be difficult to find and launch the Class Designer. What works for me is to view all my classes in the Class View window, right-click the class in question, and choose View Class Diagram.

Figure 3-20 The Class Designer

You'll learn more about the Class Designer in Chapter 6.

Pending Checkins

Both the Pending Checkin window and the Checkin window give you a concise list of what has changed in your project during your editing session. You can quickly see which files were checked out and which ones were added or edited. (See Figure 3-21.) If you don't like the flat view, you can change to a tree view—more like the one seen in Source Control Explorer. You can select or deselect the individual check boxes to have full control over what gets uploaded to Team Foundation Version Control.

Figure 3-21 The Pending Checkin window

A lot of the functionality of Source Control Explorer is duplicated in the Pending Checkin window. You can check in, shelve, or unshelve. More important, you can associate your check-in with comments, work items, and check-in notes. This is important, because your project manager might have made some of these items mandatory during a check-in.

TIP
If you're unsure what change you made during your editing session, just right-click the item in the Pending Checkin window list and select Compare, against either the workspace version or the latest version. You'll be able to see at a glance what has changed and make your decision on whether to check the file in or undo, reverting back to the original code.

Testing and Quality Tools

Whether or not developers are strictly following test-driven development, they will still need to perform unit testing and code coverage. These tests are too important to ignore altogether. I'm glad that Team System makes it so easy to create and run these tests. I hope that .NET software quality as a whole will improve because of it.

Team System has many testing tools. The following apply to developers:

• Unit Testing

  Code that exercises your project's methods

• Code Coverage

  Ensures that the unit tests cover all possible code pathways

• Static Analysis

  Ensures that your code follows established coding guidelines

• Code Profiling

  Performance based on binary instrumentation and sampling

You'll learn more about the Developer role and related tools in Chapter 6.