Test Object Model

The test object model is a large set of object types or classes that QuickTest uses to represent the objects in your application. Each test object class has a list of identification properties that QuickTest can learn about the object, a sub-set of these properties that can uniquely identify objects of that class, and a set of relevant operations that QuickTest can perform on the object.

A test object is an object that QuickTest creates in the test to represent the actual object in your application. QuickTest stores information on the object that will help it identify and check the object during the run session.

A run-time object is the actual object in your application on which methods are performed during the run session.

When QuickTest learns an object in our application, it adds the corresponding test object to an object repository, which is a storehouse for objects. we can add test objects to an object repository in several ways.

When you add an object to an object repository, QuickTest:

•    Identifies the QuickTest test object class that represents the learned object and creates the appropriate test object.

•    Reads the current value of the object's properties in your application and stores the list of identification properties and values with the test object.

•    Chooses a unique name for the test object, generally using the value of one of its prominent properties.

Test Object and Native Properties and Operations

The identification property set for each test object is created and maintained by QuickTest. The native property set for each run-time object is created and maintained by the object creator (for example, Microsoft for Microsoft Internet Explorer objects, Netscape for Netscape Browser objects, the product developer for ActiveX objects, and so on).

Similarly, a test object operation is a method or property that QuickTest recognizes as applicable to a particular test object class. For example, the Click method is applicable to a WebButton test object. As you add steps to your test, you specify which operation to perform on each test object. If you record steps, QuickTest records the relevant operation as it is performed on an object.

During a run session, QuickTest performs the specified test object operation on the run-time object. Native operations are the methods of the object in your application as defined by the object creator.

Property values of objects in your application may change dynamically each time your application opens, or based on certain conditions. You may need to modify the identification property values to match the native property values. You can modify identification properties manually while designing your test, or use SetTOProperty statements during a run session. You can also use regular expressions to identify property values based on conditions or patterns you define, or you can parameterize property values with Data Table parameters so that a different value is used during each iteration of the test. For more information on modifying object properties, see Managing Test Objects in Object Repositories.

Understanding and Using Regular Expressions.

You can view or modify the identification property values that are stored with your test in the Object Properties or Object Repository dialog box. For more information, see Specifying or Modifying Property Values.

We can view the current identification property values of any object on your desktop using the Properties tab of the Object Spy. For more information, see Viewing Object Properties and Operations Using the Object Spy.

We can view the syntax of the test object operations as well as the native operations of any object on your desktop using the Operations tab of the Object Spy. For more information, see Viewing Object Properties and Operations Using the Object Spy.

We can retrieve or modify property values of the test object during the run session by adding GetTOProperty and SetTOProperty statements in the Keyword View or Expert View. We can retrieve property values from the run-time object during the run session by adding GetROProperty statements. For more information, see Retrieving and Setting Identification Property Values.

If the available test object operations and identification properties for a test object do not provide the functionality you need, you can access the internal operations and properties of the run-time object using the Object property. You can also use the attribute object property to identify Web objects in your application according to user-defined properties. For information, see Accessing Native Properties and Operations.

Understanding Object Repository Types

Objects can be stored in two types of object repositories—a shared object repository and a local object repository. A shared object repository stores objects in a file that can be accessed by multiple tests (in read-only mode). A local object repository stores objects in a file that is associated with one specific action, so that only that action can access the stored objects.

When you plan and create tests, you must consider how you want to store the objects in your tests. You can store the objects for each action in its corresponding local object repository, or you can store the objects in your tests in one or more shared object repositories. By storing objects in shared object repositories and associating these repositories with your actions, you enable multiple actions to use the objects. For each action, you can use a combination of objects from your local and shared object repositories, according to your needs. You can also transfer local objects to a shared object repository, if required. This reduces maintenance and enhances the reusability of your tests because it enables you to maintain the objects in a single, shared location instead of multiple locations. For more information, see Deciding Whether to Use Local or Shared Object Repositories.

If you are new to using QuickTest, you may want to use local object repositories. In this way, you can record and run tests without creating, choosing, or modifying shared object repositories because all objects are automatically saved in a local object repository that can be accessed by its corresponding action. If you modify an object in the local object repository, your changes do not have any effect on any other action or any other test (except tests that call the action, as described in Inserting Calls to Existing Actions).

If you are familiar with testing, it is probably most efficient to save objects in a shared object repository. In this way, you can use the same shared object repository for multiple actions—if the actions include the same objects. Object information that applies to many actions is kept in one central location. When the objects in your application change, you can update them in one location for all the actions that use this shared object repository.

If an object with the same name is located in both the local object repository and in a shared object repository associated with the same action, the action uses the local object definition. If an object with the same name is located in more than one shared object repository associated with the same action, the object definition is used from the first occurrence of the object, according to the order in which the shared object repositories are associated with the action. For more information on associating shared object repositories, see Associating Object Repositories with Actions.

Local objects are saved locally with the action, and can be accessed only from that action. When using a shared object repository, you can use the same object repository for multiple actions. You can also use multiple object repositories for each action.

When you open and work with an existing test, it always uses the object repositories that are specified in the Associated Repositories tab of the Action Properties dialog box or in the Associate Repositories dialog box. Shared object repositories are read-only when accessed from tests; you edit them using the Object Repository Manager.