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.
