Tutorial

Overview

Download

Install guide

  Tutorial

FAQ

Using an XML repository for descriptive programming

Introduction
Need for a repository
XML Repository structure
Example

Introduction

The following sections illustrate the concept of using an XML repository for descripitive programming using quicktest scripts. This tutorial assumes that you have installed the DOR Parser and the examples that are included in the installation.

Need for an Object Repository in DP

Without going into the details of DP, here is a simple example of a line of Quicktest script that might be used to navigate to the ‘Sample Components Page’ of the web page that is shipped along with the DOR Parser installation.

a) Using Quicktest’s shared repository:-

Browser("XML OR Sample").Page("XML OR Sample").Frame("LeftFrame").Link("Sample Co").Click

b) Using Descriptive Programming:-

Browser("creationtime:=0").Page("title:=XML OR Sample Page").Frame("name:=LeftFrame").Link("text:=Sample Components").Click

Although the amount of code that goes into the two methods appear to be almost the same, the main difference is that the latter is hand-coded and the former is inserted automatically by Quicktest while recording. This obviously means that (b) has to be typed in by the user manually for every instance in the script that has to navigate to the Components page. Consider the second drawback:- Say that the text in the link is modified on a future date from Sample Components to Main Components. This would mean that all the scripts that use (b) should change to reflect this which poses a serious maintainability issue. This is not a problem in case of the Shared OR because the description of the Components Page in the OR can be modified directly and magically all the pages that use this definition are automatically updated.

Given the above argument, which one to choose ? Shared Object Repository or Descriptive Programming ? Advocates of DP would vehemently vouch for it for the various advantages that it offers. The solution to overcome the disadvantage discussed in the previous paragraph would be to have some sort of a custom object repository VBScript which is accessed by the Quicktest scripts. The problem with this approach is that such a script would be specific to the application / web site being tested and ties the data with the functions closely; Each time you want to make changes to the repository or add new items, you would have to modify the functions in the script itself which is not the most ideal solution. The second approach is to separate the data and the functions such that the database representing the object repository is one entity and the VBScript functions form the second entity. You could then store the objects in the database as key-value pairs and the scripts could retrieve the objects using these helper functions. As an illustration for the above example, the corresponding script may look something like:-

Object("Sample_Components").click
where “Sample_Components” is the name given in the database for the Components Link object.

In the solution suggested in this tutorial, an XML file forms the repository database and set of VBScript utilities are used to access this database.

XML Repository Structure

The Object Repository for descriptive programming is an XML file that has the ability to describe objects as per Quicktest’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:-

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

b) Type:- The MicClass of the object.

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 value of the Type attribute determines how the object is ‘evaluated’. The detailed description about what each of this Type attribute means will be discussed in detail in subsequent paragraphs. The <Def> element itself has one or more elements based on the Type itself.

Each <Object> element can have zero or more <Object> elements as its child elements. This hierarchical model replicates the DOM architecture. For example, the Sample Components link that was discussed 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.

The page with the title XML OR Sample Page is an immediate child of the FirstBrowser object.

The XML OR Sample Page has 3 Frames out of which the LeftFrame is one
The Sample Components link is a child of this page. So when we typed,

Browser("creationtime:=0").Page("title:=XML OR Sample Page").Frame("name:=LeftFrame").Link("text:=Sample Components").Click

Quicktest reads it as find the first created Browser, then find a Page inside this Browser that has the title “XML OR Sample Page”; Then go and find a frame that has the name “LeftFrame” and finally find a web Link that has the text “Sample Components” and click this link.

The hierarchical representation of the Sample Components link in the XML format is as follows:-

<Object_Repository>
   <Object Name="MainBrowser" Type="Browser">
       ...
       ...
       <Object Name=”SampleORPage” Type=”Page”>
           ...
           ...
           <Object Name=”LeftFrame” Type=”Frame”>
               ...
               ...
           </Object>
               <Object Name=”Components_Link” Type=”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 contents of the object ? That part is accomplished by the <Def> element that was discussed earlier. As mentioned before the <Def> element has a Type attribute which can be ParentObject, or ChildObject. The ParentObject type is used for all top level windows like Browsers, Forms, etc. The ChildObject type is used for all other objects like the Page, Link, etc.,

The ParentObject type definition element has one child element <Description>. The contents of this element is what decides how the object is evaluated. This element can assume two broad formats:-

a) Can have text enclosed within the element

b) Can have one or more child elements under it.

If the <Description> element has text within it, this text is the string that you’d use to identify the object [Object(“Text”)]. This format is mostly useful when you want to use an object straight off Quicktest’s object repository. For some cases, it is nice to use the objects from the object repository rather than identifying the object using Descriptive Programming. The best example is in case of the browser object. Although you could identify the browser object using Descriptive Programming as Browser(“creationtime:=0”), experience proves that using the browser object from the object repository itself is much quicker (as far as test execution is concerned) . In the sample object repository, you can observe that the first browser has the syntax,
  
<Description>”MainBrowser”</Description>,

In this case, “MainBrowser” is the name of the XML OR Sample Browser in the sample object repository. Of course, whether or not you want to adapt this ‘mixed mode’ approach is entirely left to your choice.

In the second case when the <Description> element has child elements, the object identification is done using ‘true’ Descriptive Programming. 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 Sample XML OR browser using this approach, the XML syntax for the browser description would be,

   <Description>
       <creationtime>0</creationtime>
   </Description>

You may use as many runtime properties as you need to identify the object. To do so, you will add as many additional elements accordingly. For example if you want to identify the browser by using the creation time and the index, your definition would look like,

   <Description>
       <creationtime>0</creationtime>
       <index>0</index>
   </Description>

The ChildObject definition type is similar to the ParentObject type in most regards. The only difference is that the description element applies only to the last element in the object tree. Thus the <Description> element for the page element has the definition,

   <Description>
       <title>XML OR Sample Page</title>
   </Description>

Note that the description for the Sample Page does not include the description for main browser. It simply inherits the properties from its parent object which is the main browser

 Likewise, the <Description> element for the left frame is

   <Description>
       <name>LeftFrame</name>
   </Description>

The component link is described as

   <Description>
       <text>Sample Components</text>
   </Description>

Thus assuming that the component 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>
               <creationtime>0</creationtime>
               <index>0</index>
           </Description>
       </Def>|
       <Object Name=”SampleORPage” Type=”Page”>
           <Def Type=”ChildObject”>
               <Description>
                   <title> XML OR Sample Page </title>
               </Description>
           </Def>
           <Object Name=”LeftFrame” Type=”Frame>
               <Def Type=”ChildObject”>
                   <Description>
                       <name>LeftFrame</name>
                   </Description>
               </Def>
               <Object Name=”Components_Link” Type=”Link”>
                   <Def Type=”ChildObject”>
                       <Description>
                           <text>Sample Components</text>
                           <html__XORSPACE__tag>A</html__XORSPACE__tag>
                       </Description>
                   </Def>
               </Object>
           </Object>
       </Object>
   </Object>
</Object_Repository>

Note the special tag which reads <html__XORSPACE__tag>. The word __XORSPACE__ has a special meaning. It is to be interpreted as a single ‘space’. Converting this tag to descriptive programming yields, “html tag:=A”.

In a similar fashion you could declare all the objects in your application and create your own Object Repository. Since the repository is an XML file, you can view the object hierarchy in a tree format using your favorite XML viewer. The attached screenshot is the view of the sample repository using Internet Explorer.

A Quicktest script using the sample XML Repository

To illustrate the use of the XML Repository in quicktest, a sample set of files have been provided with the installation. The object repository is <install_dir>\sample\xmlrepository\SampleRepository.xml and the quicktest file is <install_dir>\sample\quicktest\SampleTest.

The sample test doesn’t accomplish anything too sensible. It just navigates through the two pages that are available in the sample and then verifies that the manipulations made using the test scripts indeed happened.

All the objects are identified using Descriptive Programming with the exception of one object. The exception is the ‘Browser’ object which uses the definition from Quicktest’s object repository.

Overview

Download

Install guide

  Tutorial

FAQ