Tutorial 9: Complete Guide to Object Repository in UFT

In Tutorial 8, we learned about Native vs Identification properties in UFT. We saw that Identification properties are defined by HPE and can be thought of as a subset of Native properties in UFT. Extending the topic further, in this tutorial we will learn all about Object repository in UFT.

What is an Object Repository?

Let us understand Object repository with the help of the flow diagram above.

Depicted above are two phases; Test Design and Test Execution. During test design phase, objects in Application Under Test (AUT) are recorded and stored by UFT. During test execution phase, a UFT script is replayed where the run-time objects are compared against the stored test objects.

What do we understand by Test Objects and Run-time objects?

Test objects: Test objects are the stored representations of the actual objects in your application. As we have seen in the last tutorial, UFT identifies an object using a set of properties called Test object properties. UFT creates test objects by learning test object properties and values of the objects in your application. These test objects, their properties and corresponding values are then stored in UFT in something known as OBECT REPOSITORY abbreviated OR.

Using the objects and the properties stored inside object repository , UFT identifies object during run time.

Run-time objects: Runtime objects are the actual objects available in AUT during the execution time.

The property-value pairs of test objects AND run-time objects are compared for object identification purposes in UFT.

What are the different types of Object Repositories in UFT?

There are two different types of object repositories in UFT:

Local object repositories: As soon as you create a new action in UFT, a corresponding object repository is created along with it. This repository is known as local object repository. Any objects that are recorded in this repository are only available for the corresponding action and are not available for other actions in a test.

Local object repository is present inside the corresponding action folder and always have the name ObjectRepository.bdb

Shared object repositories: A shared object repository is an object repository that exists independently of an individual test or action. As the name suggests, the test objects present inside shared object repositories can be used by multiple tests or actions. Shared object repositories can be managed using Object Repository manager. We will discuss more about OR manager in the later advanced tutorials.

Shared object repository can have any user defined name with an extension tsr. Example: FlightReservations.tsr

[info]While recording/learning objects inside an Object repository it is recommended to store only the required objects inside it. Any extra objects that are recorded inadvertently should be deleted from the object repository. This will keep the size of repository small, help in better maintenance and performance optimization.[/info]

When to use local object repository and when to use shared object repository?

• If you are new to UFT (QTP), use local object repository. Since any new object goes in a local object repository by default, you need not bother about creating or modifying shared object repositories.
• If you are working on simple applications where you expect the object properties won’t change frequently, you may go for local object repository.
• If you work on complex applications, where you expect the object properties can change from time to time you may go for shared object repository.
• If you work on multi action tests, where you regularly use Call to Copy of Action, you may want to go for shared object repository.
• The biggest advantage of a shared object repository lies in test objects maintenance. In case a test object needs to be updated, a single update in a shared object repository will reflect across all tests/actions using that shared object repository.

Some Important points to note

• An action can be associated with both a local object repository and shared object repositories. If a given object appears in both the repositories, object definition present in local object repository will get precedence.
• If, however, an object appears in two shared object repositories, object definition present in the first occurrence of the object is used. The occurrence order depends upon the order in which the shared repositories are associated with the action.

In the next tutorial we will discuss in detail about object identification process used in UFT.
If you have not already done so, make sure you enter your name and address below to receive the next tutorial as soon as it is ready.

Here is the complete set of tutorials we have covered till now in the UFT tutorial series:

• Tutorial 1: Introduction to software testing
• Tutorial 2: Introduction to UFT
• Tutorial 3: UFT Add-ins and Add-in Manager
• Tutorial 4: All About UFT Menus
• Tutorial 5: Complete Guide to UFT Panes
• Tutorial 6: Record Your First UFT Script
• Tutorial 7: Classes and Objects in UFT
• Tutorial 8: Native vs Identification Properties in UFT
• Tutorial 10: Complete Object Identification Process in UFT