Visual Basic Concepts
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."
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.
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.
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 "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."
The following related topics provide detailed procedures:
Note ActiveX Documents cannot be debugged without a browser or other active document container. See "Building ActiveX Documents" for details.
For More Information See "Testing and Debugging ActiveX Components" for a list of topics related to testing and debugging.