Object repositories for managability of tests

An object repository is a very essential entity in any UI automation tool. A repository allows a tester to store all the objects that will be used in the scripts in one or more centralized locations rather than letting them be scattered all over the test scripts. The concept of an object repository is not tied to WET alone. It can be used for any UI test automation. In fact, the original reason why the concept of object repositories were introduced was for a framework required by QTP.

When illustrating about the object repository (In WET we call this as object depot), WET syntax will be used to make the explanation easier.

Need for an Object Repository

Let us just consider code snippets from our previous examples:

Browser("title:=Submit a bug").check_text “txt”
Browser("title:=Submit a bug").TextField("name:=Name").set “xyz”
Browser("title:=Submit a bug").TextField("name:=Email").set “abc
Browser("title:=Submit a bug").Frame(“name:=Left”).Link(“text:=Mail”).click

Notice how everything about the object has to be described – The Browser's title is 'X', which has a child TextField whose name is 'Y' and so on. Obviously in any application, the same objects will have to be re-used in many places which means that you will have to repeat the same code in every place that you use the object.

Consider the second drawback:- Say that the name of the Textfield is modified on a future date from Name to User. This would mean that all the scripts that use this line should change to reflect this. This poses a big maintainability issue. WET addresses this issue by providing support for an object repository. The object repository is an XML file that stores all the information required about the UI objects.

The XML repository has been found to be an excellent tool when it comes to managing the scripts across different versions. Small changes in the UI doesn't require an extensive recreation of the WET scripts. Simple changes in the repository is usually enough to get the scripts up and running again.

XML Repository Structure

The Object Repository is an XML file that has the ability to describe objects as per WET's requirements. The following section describes the XML Schema of the object repository. Examples are used as required, while describing the schema.

The entire database is enclosed within the <Object_Repository> element . Each Object in the repository is described within an <Object> element in the XML file. The Object element has two attributes:-

Name:- This represents the name with which this object will be identified and must be unique across the entire repository.

Type:- The type of the object – eg, Browser, TextField, etc.

Example:- The Object element for the first browser thus has the following syntax:-

<Object Name=”FirstBrowser” Type=”Browser”>
...
..

Each Object has one element that denotes the definition of the object. The name of the element for the Definition is <Def> and it has one attribute called Type. The Type attribute could have one of the following two values:- ParentObject or ChildObject. The <Def> element itself has one or more elements that helps to describe the properties of the object (which we will see in detail shortly). Each <Object> element can have zero or more <Object> elements as its child elements. This hierarchical model replicates the DOM that a browser uses while representing objects. For example, the Mail link that was used at the beginning of the document has the following hierarchical model:-
The FirstBrowser Browser object is at the top of the tree and is the parent element. It has a title of 'Submit a Bug'. It has a Frame with the name of 'Left' as its first child. This Frame itself has a child link with the text of 'Mail'

The Hierarchical representation of the Mail Link in the XML format is as follows:-

<Object_Repository>

<Object Name="MainBrowser" Type="Browser">

<!-- Write the xml structrue to identify the
browser -->

...

...

<Object Name=”LeftFrame” Type=”Frame”>

<!-- Write the xml structrue to identify the
left frame-->

..

..

<Object Name=”Mail_Link” Type=”Link”>

<!-- Write the xml structrue to identify the
Mail link -->

..

..

</Object>

</Object>

</Object>

</Object>

</Object_Repository>

Clearly from the above format, you can easily identify the parent-child relationship of various objects in the repository and the type of the object, but how do you know what is the property of each object ? That part is accomplished by the <Def> element that was talked about earlier. As mentioned before the <Def> element has a Type attribute which can be ParentObject, or ChildObject. The ParentObject type is used for the top most container – in terms of web testing always the browser.

The <Def> element one child element <Description> which in turn can have one or more child elements under it. Each child element has the syntax,

<name>value</name>

The name of each child element represents the name of the Runtime property that is required to identify the object and value is the property’s corresponding runtime value. For example, if you were to describe the 'Submit a Bug' Browser using this approach, the XML syntax for the Browser Description would be,

<Description>

<title>Submit a bug</title>

</Description>

You may use as many runtime properties as you need to identify the object. We have seen the ability of WET to identify objects using multiple parameters. To describe the object using the xml syntax:

<Description>

<text>sample text</text>

<index>2</index>

</Description>

Thus assuming that the Mail Link is the only object in the Object Repository, the XML file would look something like,

<Object_Repository>

<Object Name="MainBrowser" Type="Browser">

<Def Type=”ParentObject”>

<Description>

<title>Submit a bug</title>

</Description>

</Def>

<Object Name=”LeftFrame” Type=”Frame>

<Def Type=”ChildObject”>

<Description>

<name>Left</name>

</Description>

<Object Name=”Email_Link” Type=”Link”>

<Def Type=”ChildObject”>

<Description>

<text>Mail</text>

</Description>

</Def>

</Object>

</Object>

</Object>

</Object_Repository>

In a similar fashion you could declare all the objects in your application and create your own Object repository.