Useful Features of Visual Studio 2005


The focus of most of this chapter has been on creating a simple application, working in either Visual Basic 2005 Express Edition or Visual Studio 2005. It’s now time to leave the set of features supported by the Express Edition and look at some features that are available only to Visual Studio developers. These features include, but are not limited to, the following items, beginning with features available to all Visual Studio 2005 developers.

When Visual Studio 2005 is started, you configure your custom IDE profile. Unlike previous versions of .NET, whereby you selected a set of preferences that you would then use for all your development, Visual Studio 2005 allows you to select either a language-specific or task-specific profile and then change that profile whenever you desire.

Configuration settings are managed through the Tools image from book Import and Export Settings menu option. This menu option opens a simple wizard, which first saves your current settings and then allows you to select an alternate set of settings. By default, Visual Studio ships with settings for Visual Basic, Web Development, and C#, to name a few, but by exporting your settings you can create and share your own custom settings files.

The Visual Studio settings file is an XML file that enables you to capture all your Visual Studio configuration settings. This might sound trivial, but it’s not. This feature allows for standardization of Visual Studio across different team members. The advantages of a team sharing settings go beyond just a common look and feel.

Build Configurations

Prior to .NET, a Visual Basic project had only one set of properties. There was no way to have one set of properties for a debug build and a separate set for a release build. As a result, you had to manually change any environment-specific properties before you built the application. This has changed with the introduction of build configurations, which enable you to have different sets of project properties for debug and release builds. Visual Studio does not limit you to only two build configurations. It’s possible to create additional custom configurations. The properties that can be set for a project have been split into two groups: those that are independent of build configuration and therefore apply to all build configurations, and those that apply only to the active build configuration. For example, the Project Name and Project Location properties are the same irrespective of what build configuration is active, whereas the code optimization options vary, depending on the active build configuration. This isn’t a new concept, and it has been available to Visual C++ developers for some time, but .NET was the first time it was available for VB developers.

Currently, under Visual Studio 2005, the default settings for developers who choose to customize Visual Studio 2005 based on Visual Basic settings do not include the two build configuration settings in the project property pages. By default, Visual Basic applications are built in Debug mode until they are deployed. This enables the Visual Basic developer to be unaware of the build configuration settings. However, if a project’s build type is changed, then the VB developer is by default unaware and unable to change the setting.

To display these settings in Visual Studio, select Tools image from book Options. On the Options dialog, select the Projects and Solutions tree item; and on the settings for projects and solutions, select the “Show advanced build configurations” check box. This will update the user interface to properly display the build configurations, even though your other settings reflect those of a Visual Basic development environment.

The advantage of multiple configurations is that it’s possible to turn off optimization while an application is in development and add symbolic debug information that helps locate and identify errors. When you are ready to ship the application, you can switch to the release configuration and create an executable that is optimized for production.

At the top of Figure 13-28 is a drop-down list box labeled Configuration. Typically, four options are listed in this box - the currently selected configuration, Active; the Debug and Release options; and a final option, All Configurations. When changes are made on this screen, they are applied only to the selected configuration(s). Thus, on the one hand, when Release is selected, any changes are applied only to the settings for the Release build. If, on the other hand, All Configurations is selected, then any changes made are applied to all of the configurations, Debug, and Release. Similarly, if Active is selected, then in the background the changes are made to the underlying configuration that is currently active.

image from book
Figure 13-28

Alongside this is a Platform drop-down. Typically, you should not change this setting; its purpose is to allow you to optimize the generation of your MSIL for a specific processor. For example, 32-bit processors have different optimization than 64-bit AMD processors, which differ from Intel’s 64-bit Itanium processors. While the .NET CLR allows you to abstract these differences, Visual Studio allows you to target a specific platform.

The window below the two drop-downs displays the individual properties that are dependent on the active build configuration. The first such setting is the location where your project’s binary files will be sent. Notice that VB now defaults to separate bin/debug and bin/release directories, so you can keep separate copies of your executables. Below this is the Advanced button, which opens a window containing some low-level compiler optimizations. In most cases, you won’t need to change these settings, but they are available for those working with low-level components.

Below these settings is the All Configurations section. This label is somewhat misleading; it would be better if it said “All of the available configuration settings.” Of course, that’s a bit long, but the point is that while these settings can be different for each configuration, the grid contains all of the primary configuration settings.

All of these settings are project-specific, but when working with a solution it is possible to have more than one project in the same solution. While you are forced to manage these settings independently for each project, there is another form of project configuration related to multiple projects. You are most likely to use this when working with integrated Setup projects, where you might want to build only the Setup project when you are working on a release build.

To customize which projects are included in each build configuration, you need the Configuration Manager for the solution. Projects are assigned to build configurations through the Configuration Manager. If, and only if, your solution has multiple projects, then it is possible to open the Configuration Manager from the Build menu by selecting Configuration Manager. Alternatively, the Configuration Manager can be opened using the drop-down list box to the right of the Run button on the Visual Studio toolbar. The active configuration drop-down box contains the following options: Debug, Release, and Configuration Manager. The first two default options are the currently available configurations. Selecting the bottom option, Configuration Manager, opens the dialog box shown in Figure 13-29.

image from book
Figure 13-29

The Configuration Manager contains an entry for each project in the current solution. It is possible to include a project or exclude it from the selected configuration by clearing the check box in the column of the grid labeled Build. This is a valuable capability when a solution has multiple projects so that time isn’t wasted waiting while a project that isn’t being worked on is recompiled. The build configuration is commonly used when a Setup project is added to a solution. The normal plan is to rebuild only the Setup package when a release version of the actual application project is created. Note that regardless of the build configuration, it’s possible to build any assembly by right-clicking that project and selecting the Build option from the pop-up menu.

The Task List

The Task List is a great productivity tool that tracks not only errors but also pending changes and additions. It’s also a good way for the Visual Studio environment to communicate information that the developer needs to know, such as any current errors. The Task List is displayed by selecting Task List from the View menu. The Task List has two views, Comments and User Tasks, and it displays either group of tasks based on the selection in the drop-down box that is part of this window.

The Comment option is used for tasks embedded in code comments. This is done by creating a standard comment with the apostrophe and then starting the comment with the Visual Studio keyword TODO. The keyword can be followed with any text that describes what needs to be done. Once entered, the text of these comments shows up in the Task List. Note that users can create their own comment tokens in the options for Visual Studio via Tools image from book Options image from book Environment image from book Task List. Other predefined keywords include HACK and UNDONE.

Besides helping developers track these pending coding issues as tasks, leveraging comments embedded in code results in another benefit. Just as with errors, clicking a task in the Task List causes the Code Editor to jump right to the location of the task without hunting through the code for it. Also of note, though we are not going to delve into it, the Task List is integrated with Team Foundation Server if you are using this for your collaboration and source control.

The second type of tasks are user tasks. These may not be related to a specific item within a single file. Examples are tasks associated with resolving a bug, or a new feature. It is possible to enter tasks into the Task List manually. Within the Task List is an image button showing a red checkmark. Pressing this button creates a new task in the Task List and enables you to edit the description of your new task.

In previous versions of Visual Studio, the Task List window was used to display compilation errors, but under Visual Studio 2005 the Error List became a separate window.

The Command Window

The Command window can be opened from the Other Windows section of the View menu. When opened, the window displays a > prompt. This is a command prompt at which you can execute commands - specifically, Visual Studio commands. While Visual Studio is designed to be a GUI environment with limited shortcuts, the Command window allows you to type - with the assistance of IntelliSense - the specific command you want.

The Command window can be used to access Visual Studio menu options and commands by typing them instead of selecting them in the menu structure. For example, type File.AddNewProject and press Enter - the dialog box to add a new project will appear. Similarly, if you type Debug.Start, you initiate the same build and start actions that you would from the Visual Studio UI.

The Server Explorer

As development has become more server-centric, developers have a greater need to discover and manipulate services on the network. The Server Explorer is a feature in Visual Studio that makes this easier. Visual Interdev started in this direction with a Server Object section in the Interdev toolbox. The Server Explorer in Visual Studio is more sophisticated in that it enables you to explore and even alter your application’s database or your local registry values. With the assistance of an SQL Database project template (part of the Other Project types), it’s possible to fully explore and alter an SQL Server database. You can define the tables, stored procedures, and other database objects as you might have previously done with the SQL Enterprise Manager.

You open the Server Explorer in much the same way you open the control Toolbox. When you hover over or click the Server Explorer’s tab, the window expands from the left-hand side of the IDE. Once it is open, you will see a display similar to the one shown in Figure 13-30. Note that this display has two top-level entries. The first, Data Connections, is the starting point for setting up and configuring the database connection. You can right-click on this and define the SQL Server connection settings that will be used in your application to connect to the database. The Server Explorer is a window from the Data

image from book
Figure 13-30

Source window that opens in the same location. The Data Source window provides a way to manage and view project-specific database connections such as those used in data binding.

The second top-level entry, Servers, focuses on other server data that may be of interest to you and your application. When you expand the list of available servers (refer to Figure 13-30), you will see that you have access to several server resources. The Server Explorer even provides the capability to stop and restart services on the server. Notice the wide variety of server resources that are available for inspection or use in the project. Having the Server Explorer available means you don’t have to go to an outside resource to find, for example, what message queues are available.

By default, you have access to the resources on your local machine; but if you are in a domain, it is possible to add other machines, such as your Web server, to your display. The Add Server option enables you to select and inspect a new server. To explore the Event Logs and registry of a server, you need to add this server to your display. Use the add server button in the button bar to open the dialog and identify the server to which you would like to connect. Once the connection is made, you can explore the properties of that server.

Recording and Using Macros in Visual Studio 2005

Visual Studio macros are part of the environment and are available to any language. Macro options are accessible from the Tools image from book Macros menu, as shown in Figure 13-31. The concept of macros is simple: Record a series of keystrokes and/or menu actions, and then play them back by pressing a certain keystroke combination.

image from book
Figure 13-31

For example, suppose that one particular function call with a complex set of arguments is constantly being called on in code, and the function call usually looks the same except for minor variations in the arguments. The keystrokes to code the function call could be recorded and played back as necessary, which would insert code to call the function, which could then be modified as necessary.

Macros can be far more complex than this, containing logic as well as keystrokes. The macro capabilities of Visual Studio are so comprehensive that macros have their own IDE (accessed via Tools image from book Macros image from book Macros IDE).

Macros can also be developed from scratch in this environment, but more commonly they are recorded using the Record Temporary Macro option on the Macros menu and then renamed and modified in the development environment. Here is an example of recording and modifying a macro:

  1. Start a new Windows Application project.

  2. In the new project, add a button to Form1, which was created with the project.

  3. Double-click the button to get to its Click event routine.

  4. Select Tool_Macros_Record Temporary Macro. A small toolbar will appear on top of the IDE with a button to control the recording of a macro (Pause, Stop, and Cancel).

  5. Press the Enter key, and then type the following line of code:

      Console.WriteLine("Macro test") 

  6. Press the Enter key again.

  7. In the small toolbar, press the Stop button.

  8. Select Tools image from book Macros image from book Macro Explorer. The Macro Explorer will appear (in the location normally occupied by the Solution Explorer), with the new macro in it. You can name the macro anything you like.

  9. Right-click the macro and select Edit to get to the Macro Editor. You will see the following code in your macro:

      DTE.ActiveDocument.Selection.NewLine() DTE.ActiveDocument.Selection.Text = "Console.WriteLine(""Macro test"")" DTE.ActiveDocument.Selection.NewLine() 

The code that appears in Step 9 may vary, depending on how you typed in the line. If you made a mistake and backspaced, for example, those actions will have their own corresponding lines of code. As a result, after you record a macro, it is often worthwhile to examine the code and remove any unnecessary lines.

The code in a macro recorded this way is just standard VB code, and it can be modified as desired. However, there are some restrictions on what you can do inside the macro IDE. For example, you cannot refer to the namespace for setting up database connections, because this might constitute a security violation.

To run a macro, you can just double-click it in the Macro Explorer or select Tools image from book Macros image from book Run Macro. You can also assign a keystroke to a macro in the Keyboard dialog box in the Tools image from book Options image from book Environment folder.

One final note on macros is that they essentially enable you to generate code that can then be transferred to a Visual Studio Add-In project. An Add-In project is a project designed to extend the properties of Visual Studio. To create a new Add-In project, open the New Project dialog and select Other Project Types - Extensibility. You can then create a Visual Studio Add-In project. Such a project enables you to essentially share your macro as a new feature of Visual Studio. For example, if Visual Studio 2005 doesn’t provide a standard way to get formatted comments, you might create an add-in that enables you to automatically generate your comment template so you wouldn’t need to retype it repeatedly.

Class Diagrams

One of the new features of Visual Studio 2005 is the capability to generate class diagrams. A class diagram is a graphical representation of the objects that are part of your application. By right-clicking on your project in the Solution Explorer, you can select View Class Diagram from the context menu. Alternatively, you can choose to Add a New item to your project. In the same window where you can add a new class you have the option to add a new class diagram. The class diagram uses a “.cd” file extension for its source files. It is a graphical display, as shown in Figure 13-32.

image from book
Figure 13-32

Adding such a file to your project creates a dynamically updated representation of your project’s classes. As shown in Figure 13-32, the current class structures for even a simple project are immediately represented when you create the diagram. It is possible to add one class diagram per subdirectory in your project. The class diagram graphically displays the relationships between objects - for example, when one object contains another object or even object inheritance. The diagram itself is a living, breathing document in the sense that when you change your source code the diagram is also updated. The diagram isn’t something you create at the start of your project and then allow to become out of date as your actual implementation changes the class relationships.

More importantly, you can at any time open up the class diagram, make changes to one or more of your existing objects, or create new objects and define their relationship to your existing objects, and when done Visual Studio will automatically update your existing source files and create new source files as necessary for the newly defined objects.

As shown in Figure 13-32, the class diagram files (*.cd) open in the same main display area used for the Visual Studio UI designer and viewing code. They are, however, a graphical design surface that behaves more like Visio than the User Interface designer. Individual objects can be compressed or have their property and method details exposed. Additionally, items such as the relationships between classes can be shown graphically instead of being represented as properties.

In addition to the editing surface, when working with the Class Designer a second window is displayed. As shown in Figure 13-32, the Class Details window is generally located in the same space as your Output, Tasks, and other windows. The Class Details window provides detailed information about each of the properties and methods of the classes you are working with in the Class Designer. You can add and edit methods, properties, fields, and even events associated with your classes. While you can’t write code from this window, you can update parameter lists and property types. The Class Diagram tool is an excellent tool for reviewing your application structure.

Team System

The focus of this chapter has been on how you, as a Visual Basic developer, can leverage Visual Studio 2005. At the top end of Visual Studio 2005 is the full Team Suite, and just below that are the various Team Editions. These are part of the umbrella of products referred to as Team System. In order to reduce confusion, this section takes a brief look at the tools from Team Suite that are part of the Visual Studio 2005 Team Edition for Software Developers. These tools are focused less on languages and developing code than on managing development and the development of applications.

Architecturally, Team System has two main elements: the server-side components, which operate under Team Foundation Server, and the Client Components, which are grouped under the Team Suite umbrella. Team Foundation Server (TFS) is in a sense the replacement for Visual Source Safe (VSS). However, thinking of it only in those terms is a bit like thinking of the modern automobile as the replacement for the horse and carriage. Understandably, the focus of TFS is on server-side components, but TFS includes a client installation package. This package ships with the server, but includes add-ins to Visual Studio as well as Visual Studio Tools for Office documents that you need in order to work with the server products.

Team Suite is a set of components that are integrated with and ship with Visual Studio 2005. These components were initially categorized into three roles: Architects, Developers, and Testers. Team Suite consolidates the tools appropriate for all these roles in a single product. Since its original release, Microsoft has announced and started offering technology previews for database developers. These tools are also available to users of Team Suite. The underlying concept is that each role needs certain tools in order to better carry out the associated daily tasks, and in some cases these tools overlap between roles.

While having a single product that incorporates all these tools is nice, the cost can become an issue. Thus, Microsoft introduced the idea of Team Editions. To better manage the cost to the developer, these would provide the same server components access to all of the roles, but on the client side they would include only the tools appropriate for a specific role. Thus, from the standpoint of TFS and the server components of Team Suite, there are no differences between Team Suite and a Team Edition. The only differences exist in the tools provided as part of the client’s version of Visual Studio.

Team Foundation Server (TFS)

The server components of Team System are not directly integrated into Visual Studio 2005, but it is appropriate to mention a couple of key attributes of TFS that extend it beyond VSS. Similar to VSS, the primary role most developers see for TFS is that of source control. This is the ability to ensure that if multiple people are working on the same project and with the same set of source files, then no two of them can make changes to the same file at the same time.

Actually, that’s a bit of an oversimplification. The default mode for TFS is to allow those two people to work on the same file, and then have the second person attempting to save changes merge his or her changes with the previously saved changes. The point of this is to ensure that developers check files in and out of source control so that they don’t overwrite or lose each other’s changes. In terms of its features and usability compared with VSS, TFS is much more capable of supporting remote team members. A project that literally takes hours to download remotely from VSS can download in a few minutes from TFS.

However, that covers just the source control features, and as mentioned previously TFS goes well beyond source control. The most obvious way is that TFS approaches project development from the role of the project manager. It doesn’t consider a Visual Studio project file to represent the definition of a project. Instead, it recognizes that a project is based on a customer or contract relationship and may be made up of several seemingly unrelated projects in Visual Studio. Thus, when you define a project you create an area where all of the projects and solutions and their associated source files can be stored.

As part of the creation process you select a process template - and there are third-party templates available - and create a SharePoint website based on that template. The SharePoint website becomes the central point of collaboration for the project’s team. In addition to hosting the documentation associated with your selected software development process, this site acts as a central location for task lists, requirements, Microsoft Project files, and other materials related to your project. In essence, TFS leverages SharePoint to add a group collaboration element to your projects.

As important as this is, an even more important capability TFS supports is that of a build lab. TFS provides another optional product called Team Build, which leverages the Visual Studio build engine to enable you to schedule automated builds. This isn’t just a simple scheduling service; the Team Build engine not only retrieves and compiles your application files, it also sends update notices recognizing the status of the build, and can be instructed to automatically leverage some of the Team Suite tools such as Code Analysis and Unit Testing. The capability to automate your builds and deploy them on a daily basis to a test environment encourages processes that focus on product quality and mirror industry best practices.

Finally, TFS ships with the Team Explorer. This is a Visual Studio add-in on steroids. It includes not only new menu items for Visual Studio, but also a new window similar in concept to the Solution Explorer but that instead provides access to your TFS projects. It also provides a series of windows in Visual Studio related to source control, and others related to Tasks. TFS is in many ways the single most important tool in the Team System product line, even though it doesn’t truly exist within Visual Studio.

Team Editions

While TFS is available to all users of one of the versions of Team System, on the client side there are several different editions. As noted, Team Suite contains everything, but what about the role-based editions? There are currently three versions of the Team Edition packages: Team Edition for Architects,

Team Edition for Software Developers, and Team Edition for Software Testers. These packages are described in detail on Microsoft’s website, but here is a thumbnail review of the contents of each. Team Edition for Architects isn’t just focused on software architects. This edition contains tools oriented to the interaction of different applications, and the interaction between physical servers and the components that will be installed on those servers. The architect tools essentially work at a level above the Class Designer. These tools enable you to define applications that can then become Visual Studio projects. The designers support designating the security requirements for deploying these applications and allow the architect to compare the requirements of a given application with the settings on a physical server. The goal is to enable an architect to determine quickly whether a new application will work when it is actually deployed into production, and to understand how different applications will interact.

Team Edition for Software Developers is an excellent subset of tools for developers. The details of this edition are the focus for the following sections in this chapter. In short, the Developers edition provides tools to analyze the quality of your source code, to test an application’s performance in relation to the system resources it consumes, and to create automated unit tests. This last feature is in many ways the most important feature for improving your code quality.

Team Edition for Software Testers doesn’t focus on documenting how an application should work so much as on coding and automating tests. It has all of the same unit testing capabilities of the Developers edition but includes additional test tools for Web applications and for load testing Web applications. It also includes some basic tools for documenting and defining tests; but just as with Team Build, the focus is on being able to create and customize automated tests.

Team Edition for Developers

This set of tools, which has been integrated with Visual Studio, is focused on the needs of the application developer. Unlike the Architect tools, those for developers are to a large extent taken from existing, free tools. However, unlike those tools, the Team Suite versions have been fully integrated with Visual Studio and TFS. Don’t let the fact that many of these tools are based on freely available tools fool you; many modifications and improvements have been made.

Code Analysis

Code analysis, or static code analysis, is a tool for reviewing your source code - although that’s not quite how it works. The basic paradigm reflects the fact that there are certain common best practices when writing code, and that once you have documented these best practices it is possible to write a tool that looks at source code and determines whether these practices have been followed. Visual Studio’s static code analysis is incorporated into your project settings for Windows Formsbased projects, as shown in Figure 13-33. For Web applications, there isn’t a project file to hold the project settings, so it is possible to configure and run static code analysis from the website menu in Visual Studio.

image from book
Figure 13-33

However, the tool doesn’t actually look at your source code. Instead, it uses reflection; and once your project has been compiled, it queries the MSIL code your project generates. While this may seem surprising, remember that this tool is looking for several best practices, which may be implemented in different ways in your source code but will always compile in a standard manner.

As shown in Figure 13-33, even when you have the code analysis tools available, they are by default not enabled for your project. This is because enabling code analysis significantly extends your compile time. In most cases you’ll want to enable these settings for a build or two, and then disable the checks for most of your debug builds. As you can see, to enable analysis you merely check the Enable Code Analysis check box.

Once you have enabled the code analysis checks, you also have the option to define exactly which rules you want to apply. Figure 13-33 illustrates that the checks are divided into different categories of rules, with a corresponding status for each category. The status shown in this configuration screen describes what should happen if you fail to pass one of these rules in a given category. It is not an indicator of the current state of your code.

Instead, this status represents what should be reported as part of your compilation results when you have enabled code analysis. Note that each of the categories can be enabled or disabled as part of your code analysis. It is then possible to expand the display to list the rules in each category. This enables you to have some rule violations act as compilation errors instead of warnings. You can also enable or disable having the analyzer check individual rules. Outside of the scope of this chapter is the capability to actually identify within your source code those items that may be flagged by the code analyzer but that are valid exceptions to the rule being checked.

Performance Tools

Performance checks are something every developer talks about wanting. Visual Studio provides dynamic code analysis, or performance, tools for your application. These tools are available from the Tools menu, shown in Figure 13-34. The performance tools provide two runtime environments to measure the performance of your application: Sampling and Instrumented. Note that if you are working within a virtual PC, then you need to use the instrumented version of the performance tools.

image from book
Figure 13-34

Sampling for performance testing is a non-intrusive method of checking your application performance. Essentially, Visual Studio starts your application normally, but behind the scenes it is interfaced into the system performance counters. As your application runs, the performance monitoring engine captures the system performance, and when your application completes it provides reports describing that performance. Details about what your application was actually doing to cause a behavior isn’t available, but you can get a realistic feel of the impact on the system.

Instrumentation, conversely, is an intrusive form of performance monitoring. Choosing to make an instrumentation run the performance tools triggers the addition of special MSIL commands into your compiled executable. These calls are placed at the start and finish of methods and properties within your executable. Then, as your code executes, the performance engine can gauge how long it takes for specific calls within your application to execute.

Keep in mind that both methods of performance testing affect the underlying performance of the application. It is true that running a performance monitor of any type has built-in overhead that affects your application. However, the goal of performance testing isn’t to know the exact timing marks of your application, but rather to identify areas that deviate significantly from the norm, and, more important, to establish a baseline from which you can track any significant changes as code is modified.

Unit Tests

Automated unit tests are arguably the most important of the tools provided to the developer as part of Team Edition. To create a new Unit Test, go to the Test menu in Visual Studio and select New Test. This opens the Add New Test dialog, shown in Figure 13-35.

image from book
Figure 13-35

Note that the dialog shown in Figure 13-35 isn’t from Visual Studio 2005 Team Edition for Software Developers. It is from Visual Studio 2005 Team Suite, the difference being several more project templates, representing the full suite of templates available to a Software Tester. Developers will normally only see the Unit Test and Unit Test Wizard templates available in this screen. Given this, developers should work with the Unit Test Wizard to generate new tests. This wizard walks you through the process of generating a new test project.

Once you have completed the final step in the wizard to define your test project, you are presented with the screen shown in Figure 13-36. This screen shows each of your project’s classes, and expands into the methods and properties available in that class. Note that the screen shown is based on the ProVB.NET sample application, which consists of a single form. Displayed are several inherited methods in addition to the custom methods on the form. In fact, the custom methods are not shown in the figure. This screen enables you to review those properties and methods that are part of the My namespace. Specifically, you can run tests against the settings and resources that you expect will be included in your project.

image from book
Figure 13-36

What’s missing is any type of review of the actual UI elements that a user of your application would interact with. The unit test engine that ships with Team System does not support actual UI testing; it is focused on testing methods that exist in your code. However, the purpose of this screen is to enable Visual Studio to generate the source code associated with testing your application. Clicking the OK button triggers the generation of these tests, which will be grouped in a new test project. Because the project name shown in Figure 13-36 wasn’t customized, you’ll see the newly generated project in Figure 13-37.

image from book
Figure 13-37

The creation of a Unit Test project is not a trivial event. Even though it occurs as quickly as any other project template, the results are significant. First, notice in the Solution Explorer shown in Figure 13-37 that another project has been added to the ProVB.NET solution. This new test project includes a documentation file, AuthoringTests.txt, with tips and instructions for writing unit tests. In addition, this screen shows a subset of the contents of the Form1Test.vb source file. It is opened to some of the comments accompanying the methods stubs to implement the tests for your selected methods.

Unit tests present a unique challenge - because you are writing test code, they are an expensive feature to initially implement. Therefore, even though automated unit tests are valuable, organizations often have trouble committing to their development. Nonetheless, a well-written set of tests more than pays for itself. How do you estimate that cost? As a rule of thumb, consider estimating as much time for writing tests as you expect to spend writing the code to be tested.




Professional VB 2005 with. NET 3. 0
Professional VB 2005 with .NET 3.0 (Programmer to Programmer)
ISBN: 0470124709
EAN: 2147483647
Year: 2004
Pages: 267

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net