Microsoft Visual Basic 6.0 Reference Library

Chapter 7: Debugging, Testing, and Deploying Components

This chapter describes the procedures you'll use to debug, register, and distribute your component, and the version compatibility features that allow you to enhance your component without breaking existing applications that use it.

In addition, you'll find topics related to distributing components, including Help files, browser strings, and creating versions of your component for use internationally.

Chapter 6, "General Principles of Component Design," contains a road map relating the topics covered in these two chapters to the general sequence of development tasks for components.

Contents

• Testing and Debugging ActiveX Components
• Generating and Handling Errors in ActiveX Components
• Providing User Assistance for ActiveX Components
• Deploying ActiveX Components
• Version Compatibility in ActiveX Components
• Localizing ActiveX Components

For More Information See Chapter 13, "Debugging Your Code and Handling Errors"; Chapter 16, "International Issues"; and Chapter 17, "Distributing Your Applications," in the Microsoft Visual Basic 6.0 Programmer's Guide.

Jesting and Debugging ActiveX Components

Visual Basic provides two different component debugging scenarios. For in-process components, you can load a test project (Standard EXE or ActiveX EXE) and one or more component projects into the development environment as a project group. You can run all the projects in the group together, and step directly from test project code into in-process component code.

Out-of-process components can be debugged using two instances of the development environment. One instance of Visual Basic runs the test project, while the second runs the component project. You can step directly from test project code into component code, and each instance of Visual Basic has its own set of breakpoints and watches.

Combinations of these scenarios are possible. You can debug an application that uses both in-process and out-of-process components, as shown in Figure 7.1.

When an ActiveX EXE project is in run mode, like MyComponent in Figure 7.1, the client application (MyApp) can create objects and access their properties and methods. Each out-of-process component a client uses must be in its own instance of the development environment. The client application and all of its in-process components - DLLs and OCXs can run together in a single instance of the development environment.

For More Information
There are special considerations for debugging and testing ActiveX control projects, and other project types that include private controls. See "Setting Up a New Control Project and Test Project" and "Debugging Controls," in Chapter 9, "Building ActiveX Controls." Information specific to debugging and testing ActiveX Documents can be found in Chapter 11, "Building ActiveX Documents." The fundamentals of debugging are covered in Chapter 13, "Debugging Your Code and Handling Errors," in the Microsoft Visual Basic 60 Programmer's Guide.

How to Test ActiveX Components

To test a component, you need to create a client application. Components exist to provide objects for clients, which makes it hard to test them by themselves.

Your test project should invoke all the properties, methods, and events of each object provided by your component, testing both valid and invalid values of all arguments.

For example, rather than simply making one call to the Spin method of the Widget object, make a series of calls that try valid and invalid values of all arguments. Pay particular attention to the highest and lowest valid values, as these boundary conditions are a frequent source of problems.

Test for both functionality and error cases. Make sure your component behaves well in case of errors, such as unexpected input. It's especially important to make sure you've covered all error conditions in event procedures of in-process components, because such errors can be fatal to client applications that use the component.

Tip: Your test project can also be used to test the compiled component, as described in "How to Test Compiled Components," later in this chapter.

Make the Test Program Generic for Better Coverage

You can improve your testing process by making the test program more generic. For example, if you create a text box for each argument of the Spin method, and a button to invoke the method, you can use an automated test tool to maintain and run comprehensive test suites. This makes it easier to test combinations of properties and methods.

Testing Components as Part of an Application

If you're creating components as part of an application, you can use the application itself as the test program. In theory, thorough testing of the application will discover any problems with its components.

In practice, however, this is rarely true. An application may not exercise all the interfaces of the components it uses, even under stress testing.

It's also a lot more work to set up test cases when you have to figure out what application behavior must be tested in order to test a particular feature of the component. You'll be better served by a comprehensive test program that directly tests each element of each object's interface.

If each component has been tested separately, testing your application with the components provides an extra level of quality assurance.

Creating a Test Project

The test project must be an EXE project. Unless you're testing call-backs, your test project can be a Standard EXE project. To test call-backs, use an ActiveX EXE project, so it can include public classes that implement the call-back methods. Call-backs are discussed in "Asynchronous Call-Backs and Events," in Chapter 8, "Building Code Components."

The way you set the test project up depends on whether you're testing an in-process or out of process component. The reason for this is explained in "Testing and Debugging ActiveX Components."

Note: ActiveX Documents cannot be debugged without a browser or other active document container. See Chapter 11, "Building ActiveX Documents," for details.

For More Information See "Testing and Debugging ActiveX Components," earlier in this chapter, for a list of topics related to testing and debugging.

Creating a Test Project for an In-Process Component

This section explains how to set up test projects to exercise most of the objects in-process components can provide. ActiveX documents, however, cannot be tested as described here. For more information, see Chapter 11, "Building ActiveX Documents."

To create a test project for an in-process component

1. The test project is loaded in the same copy of the development environment where your component project is loaded. On the File menu, click Add Project to open the Add Project dialog box, click the Standard EXE icon to select it, then click OK to add a Standard EXE project to the project group.

The caption of the Project window changes to Project Group, with a default name, to indicate that multiple projects are loaded.

As described in "How to Test ActiveX Components," use an ActiveX EXE project as your test project if your component implements call-backs.

2. On the File menu, click Save Project Group to save the group containing the component and test project. From now on, you can open both projects simply by opening the project group.

3. (ActiveX control components skip this step.) Make sure the test project is active - that is, that one of its files is highlighted in the Project window. On the Project menu, click References to open the References dialog box. Locate your component in the list, and check it. . . .