Test Objects in Object Repositories

Relevant for: GUI tests an components

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 or components (via their application areas) (in read-only mode). You can use the same shared object repository for multiple actions or components. You can also use multiple object repositories for each action or component.

A local object repository stores objects in a file that is associated with one specific action or component, so that only that action or component can access the stored objects. The local object repository is automatically created when you create a new action or component.

When you plan and create tests or components, you must consider how you want to store their test objects. You can:

  • Store the objects for each action or component in its corresponding local object repository.

  • Store the objects in one or more shared object repositories. By storing objects in shared object repositories and associating these repositories with your actions or component’s application areas, you enable multiple actions and components to use the objects. Use a combination of objects from your local and shared object repositories, according to your needs.

To choose where to save objects, you need to understand the differences between local and shared object repositories:

Use this object repository type...

In these situations...

local object repository

  • You are creating single-action tests.

  • You are creating simple tests or components, especially under the following conditions:

    • You have only one, or very few, tests or components that correspond to a given application, interface, or set of objects.

    • You do not expect to frequently modify object properties.

    • You are new to using UFT. You can record and run tests or components 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 or component.

shared object repository

  • You are creating tests or components using keyword-driven methodologies (not by recording).

  • You have several tests or components that test elements of the same application, interface, or set of objects.

  • You often work with multi-action tests and regularly use the Insert Copy of Action and Insert Call to Action options.

  • You expect the object properties in your application to change from time to time and/or you regularly need to update or modify object properties.

  • 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 or components—if they use the same objects.

    Object information that applies to many actions or components is kept in one central location. When the objects in your application change, you can update them in one location for all the actions and components that use this shared object repository.

Note: If you want to use a shared object repository from ALM, you must save the shared object repository in the Test Resources module in your ALM project before you associate the object repository using the Associated Repositories tab of the Action Properties dialog box or the Associate Repositories dialog box.

You can save the shared object repository to your ALM project using the Object Repository Manager (as long as the Object Repository Manager is connected to your ALM project).

If you have an object with the same name in multiple associated repositories:

  • 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 or component, the local object definition is used.

  • If more than one shared object repository is associated with the same action or component, 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 or component.