VB6 beginners tutorial - Learn VB6

Advanced VB6 tutorial - Learn Advanced VB6

Systems Analysis - System analysis and Design tutorial for Software Engineering

You are here: Visual Basic > Advanced VB6 tutorial > Chapter 13

What to Look for When Testing Your ActiveX Control

In the following sections, we discuss some considerations for testing the features that you have built into your custom ActiveX control.

In order to test these features, you must run a test project against your control, as discussed in the previous sections.

Here is a list of things you should do to make sure that your control behaves in a way that developers will recognize as standard control behavior.

  • Use an instance of your control to test its methods by calling each method in code from the code of the test project.

  • Test your control's events by placing an instance of your control in the test project. Then follow these steps for each event:

    • Write code in the test project that will trigger the event (what the test code needs to do depends on how you've designed the event).

    • In the test project's code, find the event procedures for your control instance's events. Then put code in the event procedures that will test whether the event fired.

    Debug.Print messages are a good idea. Message boxes are not such a good idea because they can interrupt the flow of processing, especially when keyboard input is important. Also include code to test the value of any parameters passed by the event procedure.

  • Test your control's properties by placing an instance of your control in the test project. Make sure you test the following features of each property:

    Make sure that the control starts with its properties initialized to their default values: Add an instance of your control to the test project and make sure that the initial property values are what you expect. You should have specified default values in the UserControl's InitProperties event procedure.

    Make sure that default values don't overwrite developer changes when the project goes from design time to runtime:

    This might happen if you've mistakenly assigned default values in the ReadProperties event procedure.

    Make sure that design time changes to controls persist to runtime. Check the WriteProperties and ReadProperties event procedures as well as the Property Let/Set and Get procedures if there are problems. Make sure you're calling the PropertyChanged method in Property Let/Set procedures.

    Make sure that runtime changes actually take effect at runtime: Make sure you're storing property values in the appropriate intermediate variables or underlying delegated properties in the Property Let/Set procedures.

    Make sure that data-bound properties correctly reflect underlying data: If you have implemented data-bound properties, then check your control's properties for a DataSource property. (If it's missing it means you haven't designated any property as the DataField property). Put a Data Control on your test form, connect it to data, and set the DataSource property to point to the Data Control. Then set the DataField and other data-bound properties to point to the fields provided by the Data Control's Recordset.


<< Previous | Contents | Next (Chapter 14) >>

Home | About Us | Privacy Policy | Contact Us

Copyright © | All Rights Reserved