Tools for Developers

Visual Studio 2005 Team System provides many new tools specifically for developers, primarily in the areas of source-code control, class designing, and unit testing.

Source Control Explorer

When working on projects under source control, the Source Control Explorer window is very important. It shows all the projects under source control on the Team Foundation Server, based on permission settings. (See Figure 3-7). 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-7

Source Control Explorer

Class Designer

The new Class Designer is another example of a Domain-Specific Language. The Class Designer is part of Visual Studio 2005 Professional, but it also very interregnal to VSTS.

One of the last steps that a solution 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.

The Class Designer is a graphical environment, where each class is represented by a rectangular shape. Any properties, methods, fields, and events will be listed on the shape. (See Figure 3-8.) Users can expand and collapse the member list, depending on the real-estate constraints. Users can right-click on the shape and add new members, or can work directly in the Class Details window, which allows the management of all class members in one easy-to-use grid.

Figure 3-8

The Class Designer

The best part about the Class Designer is that it is tightly coupled with the source code file behind it. In other words, if a file is 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 is no reverse or round-trip engineering steps required-another advantage of a Domain-Specific Language tool.

Pending Checkins

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

Figure 3-9

The Pending Checkin window

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

Testing Tools for Developers

Whether or not developers are strictly following test-driven development, they will still need to perform unit testing and code coverage. VSTS has a large number of default tests with many applying to developers:

Unit Testing

Code that exercises the project's methods

Code Coverage

Ensures that the unit tests cover all possible code pathways

Static Analysis (click here to view the video for Static Analysis for Unmanaged Code)

Ensures that the code follows established coding guidelines

Code Profiling

Performance based on binary instrumentation and sampling