IBM Rational Functional Tester Creating Custom Verification Point

In addition to the flexibility of being able to use datapool references in verification points created with the Rational Functional Tester Verification Point Wizard, you can create your own dynamic verification points in code. RationalTestScript (the root of all script classes) has a method, vpManual(), which you can use to create verification points.

vpManual() is used when you want your script to do all the work of verifying data. That work consists of capturing expected data, capturing actual data, comparing actual data with expected data, and logging the results of the comparison. Think of manual as referring to manual coding.

This discussion begins with the first signature (which you will likely use most often). In vpManual’s three-argument version, you supply a name for your verification point along with the baseline and actual data associated with the verification point. vpManual() then creates and returns a reference to an object; specifically, one that implements Rational Functional Tester’s IFtVerificationPoint interface. The verification point metadata (name, expected, and actual data) are stored in the returned IFtVerificationPoint.

IFtVerificationPoint myVP = vpManual( "FirstName", "Sasha", "Pasha");

Dim myVP as IFtVerificationPoint = vpManual( "FirstName", "Sasha", "Pasha" )

There are a couple of items to note about using vpManual():

* vpName— The verification point name must be a script-unique valid Java (or .net) method name and be less than 30 (.net) or 75 (Java) characters.

* Baseline and Actual data— The compiler accepts a reference to anything that inherits from Object (which means that in .NET, any argument you pass is acceptable; Java allows anything other than primitives, such as int, bool, and so on); however, you need to satisfy more than the compiler. To automate the comparison of baseline with actual data, you need to pass data types that Rational Functional Tester knows how to compare (you don’t want to have to build your own compare method). This limits you to passing value classes. Some examples of legal value classes are: any data returned by getTestData(), strings, primitives, wrapper classes (Integer, Boolean, and so on), common classes that consist of value class fields (for example, Background, Color, Bounds, ITestData, meaning, anything returned by getTestData()), and arrays (one and two-dimensional), vectors, and hashtables that contain value class elements.

What do you do with the IFtVerificationPoint that vpManual() returns? In the simplest case, you call performTest() and get on with things. performTest() compares the baseline with the actual and logs the results (boolean) of the comparison.

A simple comparison

Java

IFtVerificationPoint myVP = vpManual( "FirstName", "Sasha", "Pasha");

boolean passed = myVP.performTest();

VB.NET

Dim myVP As IFtVerificationPoint = VpManual("FirstName", "Sasha", _ "Pasha")

Dim passed As Boolean = myVP.PerformTest

In two lines of code, you have done quite a bit. You created a verification point and compared and logged the results of comparing the baseline to the actual data. It’s common to combine these two statements into one:

vpManual( "FirstName", "Minsk", "Pinsk").performTest();

You use this style when the only method you need to invoke on the IFtVerificationPoint returned by vpManual() is performTest().

It’s important to note that the three-argument version of vpManual() does not persist baseline data to the file system for future runs. It’s also important to stress the importance of the uniqueness of the name in the script.

To illustrate how Rational Functional Tester behaves when a verification point is not unique, consider the simple example where vpManual is called in a loop (demonstrated in below code). The loop in each code sample simply compares two numbers. To introduce some variety, you force the actual value to equal the baseline value only when the baseline value is even.

Consequences of a nonunique verification point name

Java

for(int baseline = 1; baseline <= 10; baseline++ ) {

int actual = baseline % 2 == 0 ? baseline : baseline + 1;

vpManual("CompareNumbers", baseline, actual).performTest();

}

VB.NET

For baseline As Integer = 1 To 10

Dim actual As Integer

If (baseline Mod 2 = 0) Then

actual = actual

Else

actual = baseline + 1

End If

VpManual("CompareNumbers", baseline, actual).PerformTest()

Next

If you execute this code, you see two interesting results in the log:

• The pass/fail status for each verification point is what’s expected (half pass, half fail).

• The comparator shows the correct actual values for each verification point, but a baseline value of 1 for every verification point. The reason for this is that after an IFtVerificationPoint has been created, the baseline cannot be updated.

The common technique to deal with this issue (in a looping context) is to append a counter to the verification point name, guaranteeing a unique name per iteration. This is shown in below code

Guaranteeing a unique verification point name

Java

for(int baseline = 1; baseline <= 10; baseline++ ) {

int actual = baseline % 2 == 0 ? baseline : baseline + 1;

vpManual("CompareNumbers_" + baseline, baseline,

actual).performTest();

}

VB.NET

For baseline As Integer = 1 To 10

Dim actual As Integer

If (baseline Mod 2 = 0) Then

actual = actual

Else

actual = baseline + 1

End If

VpManual("CompareNumbers_" & baseline, _

baseline, actual).PerformTest()

Next

Persisting Baseline Data

In addition to the three-argument version of vpManual(), there is a two-argument version of vpManual():

IFtVerificationPoint vpManual( String vpName, Object data )

The two-argument version is used when you want to persist the baseline data to the Rational Functional Tester project. Here’s how it works. The first time performTest() is called on an IFtVerificationPoint with a given name (the name passed to vpManual()), no comparison is done. The baseline data is written to the RFT project and a verification point displays in the Script Explorer (and an informational message is written to the log). With each subsequent execution of performTest() on an IFtVerificationPoint with the same name, the data argument passed to vpManual() is treated as actual data, and performTest() executes the comparison, logging the result.