QuickTest’s Custom CheckPoints and Beyond

This article will discuss the concepts of Custom Checkpoints, their benefits, when to use them and how they provide us with greater flexibility in script development. Custom CheckPoints offer an easier and highly flexible way of constructing your object verifications, which is a core concept of test automation. The concepts below, when coupled together can help you build extremely robust scripts, with enough information that your user desires.

Before we begin creating CheckPoints as we would for our application(s), let’s do a quick walk-through of the Reporter Object.

Reporter Object

According to QTP help:

Description: The object used for sending information to the test results.

We use the Reporter object along with its ReportEvent method to send the necessary information to the test results:

ReportEvent: Reports an event to the test results.

Below is the syntax of Reporter.ReportEvent method:

Reporter.ReportEvent EventStatus, ReportStepName, Details [, Reporter]

Possible choices for ReportEvent are:

0 or micPass: Causes the status of this step to be passed and sends the specified message to the report.
1 or micFail: Causes the status of this step to be failed and sends the specified message to the report. When this step runs, the test fails.
2 or micDone: Sends a message to the report without affecting the pass/fail status of the test.
3 or micWarning: Sends a warning message to the report, but does not cause the test to stop running, and does not affect the pass/fail status of the test.

Example:

Reporter.ReportEvent micDone, "Step 1", "Step Done."

I wanted to cover the Reporter object real quick because its a core-concept in creating custom checkpoints. We’ll begin creating them now!

Custom CheckPoints and the Exist Method

This is an extremely important concept, and in my opinion, it should serve as the base to all CheckPoints. It checks whether an object exists on the page or not, and before we can start verifying an object’s properties, it’s important that we check if it is even available to us to perform our verifications. Also, if the object is found in the applicantion, the Exist method returns true, else, it returns false. Syntax:

Object.Exist(Timeout)

In the syntax above, Timeout is the amount of time you would like QTP to wait for the object before it returns a boolean output. Let’s see 2 examples of its use.

Case where an object is found

To check if the Text box exists, we can formulate the following code that will wait for a max of 5 seconds before the WebEdit appears on the page:

MsgBox Browser("title:=.*Relevant Codes.*").Page("micclass:=Page")_
        .WebEdit("name:=txtExistTest").Exist(5)

Case where an object is not found

Let’s use the same example above, and run the same check for the text box below:

MsgBox Browser("title:=.*Relevant Codes.*").Page("micclass:=Page")_
        .WebEdit("name:=txtNotFound").Exist(5) 'False

You may spy on the WebEdit above (just to make sure), and notice that there is actually a textbox with the description we provided. But, still, QuickTest returns a failed status. That is because, for this example, I created 2 such text boxes with the exact same description, so if you just provide the property without an Ordinal Identifier, your code will not work. However still, I feel the above is quite a good example of a scenario that can very well happen in many applications and its a good test of an automation engineer to be cautious from the start.

However, we still haven’t created a CheckPoint yet. A CheckPoint is a conditional method that information the user of an objects’ status during testing. Thus, we must create a conditional method here:

If Browser("title:=.*Relevant.*").WebEdit("name:=txtNotFound").Exist(5)
	Reporter.ReportEvent micPass, "WebEdit CheckPoint", "WebEdit was found. Step Passed."
Else
	Reporter.ReportEvent micFail, "WebEdit CheckPoint", "WebEdit was not found. Step failed."
End If

There you go! You have just created a custom CheckPoint. If you would like to know more about the Reporter object, please use the QTP help, which is an excellent source of information.

Custom CheckPoints and the GetROProperty Method

GetROProperty is short for Get-Runtime-Object-Property. In other words, this method can be used to retrieve the value that the object has, at present. Please note that, in some dynamic applications, runtime object properties can change on various factors. Also, with Descriptive Programming (DP), regardless of what property you retrieve, it will always be a runtime property. Obviously, and I bet you know this, but just to reiterate, all these properties can be viewed from the Object Spy. You can find more information on it in my article Descriptive Programming 1. Below is a snapshot of the TO Properties Tab in Object Spy:

QTP Object Spy TO Properties

You will notice that even though I mentioned RO (RunTime Object) properties, I am looking at the TO (Test Object) tab. This is because, when we use the Object Spy to retrieve an objects’ properties, we are doing it on a runtime object, thus, what we see in the image above are all RunTime object properties with their image in the TO Object properties tab. We will use the GetROProperty method with TO properties.

Also, when writing custom checkpoints, we will (almost) always use RO properties instead of TO properties. That is because, we would like to know what the object contains at present, or at runtime as opposed to what the object contained during record time. However, if you are using Descriptive Programming, regardless of what property you retrieve from your application, it will be a runtime property.

The textbox below should have a value of 10, for the maxLength property. We will create a checkPoint to test that assumption.

If Browser("title:=.*Relevant.*").WebEdit("name:=txtMaxLen").GetROProperty("max length")=10 Then
	Reporter.ReportEvent micPass, "WebEdit MaxLength Text", "Test Passed."
Else
	Reporter.ReportEvent micFail, "WebEdit MaxLength Text", "Test Failed."
End If

Result:

QTP Results

QTP Results

When you open your Test Results after the above statement executes, you will notice that, the test failed. It will always fail because the maxLength for our WebEdit is not 10, but 9. When you you use Object spy to retrieve the max length property, you will notice that it is indeed not 10, but its 9. However, in the real-world, we may not always know the properties these objects will have at runtime, and most of the times you will come to find of errors after your regression suites complete their execution.

Let’s create another CheckPoint, and verify if the Link has the correct color:

Relevant Codes: Test Color

With Browser("title:=.*Relevant Codes.*").Link("text:=Relevant Codes: Test Color")
	If .Exist(5) Then
		If .GetROProperty("color") = "#0000ff" Then
			Reporter.ReportEvent micPass, "RelevantCodes Link", "Correct color."
		Else
			Reporter.ReportEvent micFail, "RelevantCodes Link", "Incorrect color."
		End If
	Else
		Reporter.ReportEvent micFail, "RelevantCodes Link", "Link was not found."
	End If
End With

Result:

QTP Results

QTP Results

CheckPoints for Multiple Objects

There are circumstances where you need to create CheckPoints for multiple objects at once. For instance, if you are creating a Login Function, you may need to create a CheckPoint for the UserName Textbox, Password Textbox and the Submit button. This section of the article details how CheckPoints can be created for multiple objects.

This article shows a way to verify multiple Object Properties through a single Class at once, and reports all Checks in a tabular form to QuickTest Results.

Below, you will see a scenario that I just mentioned above. These objects won’t do anything, but, they show a way you can create CheckPoints to be run for multiple objects together.

With Browser("title:=.*Relevant Codes.*").Page("micclass:=Page")
    If .WebEdit("name:=txtUser").Exist(1) And .WebEdit("name:=txtPassword").Exist(1) Then
        Reporter.ReportEvent micPass, "UserName/Password", "Objects found."
    Else
        Reporter.ReportEvent micFail, "UserName/Password", "Objects not found."
    End If
End With

Multiple Checks - Results

Multiple Checks - Results

Similarly, if we want to verify objects’ properties instead of checking whether they exist, we can do this:

With Browser("title:=.*Relevant Codes.*").Page("micclass:=Page")
    If .WebEdit("name:=txtUser").GetROProperty("max length") = 9 And _
     .WebEdit("name:=txtPassword").GetROProperty("max length") = 9 Then
        Reporter.ReportEvent micPass, "UserName/Password", "Correct MaxLength"
    Else
        Reporter.ReportEvent micFail, "UserName/Password", "Incorrect MaxLength"
    End If
End With

QTP Results

QTP Results

CheckPoints for Hidden Objects

Let’s create another CheckPoint. This time, things will get a little complex. Below you will see a Textbox, but indeed there are 2. One of them is hidden. Is there a way to know that one of these Text boxes is hidden? The answer is: Yes.

With Browser("title:=.*Relevant Codes.*")
'If the first text box, that is, the text box with index 0 is hidden then.. set value in Text Box #2
    If .WebEdit("name:=txtIsVisible", "index:=0").GetROProperty("visible") = False Then
        Browser("title:=.*Relevant Codes.*").WebEdit("name:=txtIsVisible", "index:=1").Set "2nd"
    Else
        'Else, set value in Text Box #1
        Browser("title:=.*Relevant Codes.*").WebEdit("name:=txtIsVisible", "index:=0").Set "1st"
    End If
End With

In practice, many people make the mistake of omitting an ordinal identifier in such cases. When you run the same code without an ordinal identifier:

'Error
MsgBox Browser("title:=.*Relevant Codes.*").WebEdit("name:=txtIsVisible").GetROProperty("visible")

You can generally run the following bit of code to find out which object is hidden:

Set oDesc = Description.Create
oDesc("name").value = "txtIsVisible"
 
Set colObject = Browser("title:=.*Relevant Codes.*").Page("micclass:=Page").ChildObjects(oDesc)
 
For x = 0 to colObject.Count - 1
	Print "Object " & x & ": " & colObject(x).GetROProperty("visible")
Next

In your print log, you will have the following information:

'Object with Index = 0 is Hidden
Object 0: False

'Object with Index = 1 is not Hidden
Object 1: True

There are more ways to hide objects, and there are several techniques that can be used to spot them. However, I will let my readers explore those scenarios and find the many possibilities available to them.

I hope this article clarifies some doubts, and gives you more confidence using them in your everyday development.

Tagged as: .Exist, Custom Checkpoint, DP, QTP, QTP CheckPoints, QTP Custom CheckPoints, QTP Reporter