Although you can account for differences in the appearance of your application in the window declarations, if the application’s behavior is fundamentally different when ported, you need to modify your test cases themselves. To modify your test cases, you write sections of 4Test code that are platform-specific, and then branch to the correct section of code using the return value from the GetGUIType built-in function.
This topic shows how to use the GetGUIType function in conjunction with if statements and the switch statements.
You can use GUI specifiers before an entire switch statement and before individual statements within a case clause, but you cannot use GUI specifiers before entire case clauses.
testcase GUISwitchExample()
INTEGER i
FOR i=1 to 5
mswxp, mswnt switch(i)
// legal:
mswxp, mswnt switch (i)
case 1
mswxp Print ("hello")
mswnt Print ("goodbye")
case 2
mswxp raise 1, "error"
mswnt Print ("continue")
default
mswxp Print ("ok")
// NOT legal:
switch (i)
mswxp case 1
Print ("hello")
mswnt case 1
Print ("goodbye")
You can use GUI specifiers in if statements, as long as GUI specifiers used within the statement are subsets of any GUI specifiers that enclose the entire if statement.
// legal because no GUI specifier
// enclosing entire if statement:
if (i==j)
msw32, mswnt Print ("hi")
msw2000 Print ("bye")
// legal because msw is a subset of enclosing specifier:
msw32, msw2000 if (i==j)
mswnt Print("hi")
// legal for the same reason as preceding example:
msw32, msw2000 if (i==j)
Print ("hi")
mswnt else
Print ("Not the same")
// NOT legal because msw2000 is not a subset
// of the enclosing GUI specifier msw:
msw32 if (i==j)
msw2000 Print ("bye") // Invalid GUI type
If you are trying to test multiple conditions, then you should use a select or switch block. You could use nested if.else statements, but if you have more than two or three conditions, the levels of indentation will become cumbersome.
You should not use an if..else if..else block. Although if..else if..else will work, it will be difficult to troubleshoot exceptions that occur because the results file will always point to the first if statement even if it was actually a subsequent if statement that raised the exception.
For example, in the following test case, the third string, Not a date, will raise the exception:
*** Error: Incompatible types -- 'Not a date' is not a valid date
The exception actually occurs in the lines containing:
GetDateTimePart ([DATETIME]sVal, DTP_YEAR) == 2006
For the nested if..else and the select blocks, the results file points to those lines as the sources of the exceptions. However, for the if..else if..else block, the results file points to the first if statement, in other words to the line:
[-] if IsNull (sVal)
even though that line clearly is not the source of the exception because it does not concern DATETIME values.
[+] testcase IfElseIfElse ()
[-] LIST OF STRING lsVals = {...}
[ ] "2006-05-20"
[ ] "2006-11-07"
[ ] "Not a date"
[ ] STRING sVal
[ ]
[-] for each sVal in lsVals
[-] do
[-] if IsNull (sVal)
[ ] Print ("No date given")
[-] else if sVal == FormatDateTime (GetDateTime (), "yyyy-mm-dd")
[ ] Print ("The date is today")
[-] else if GetDateTimePart ([DATETIME]sVal, DTP_YEAR) == 2006
[ ] Print ("The year is this year")
[-] else
[ ] Print ("Some other year")
[-] except
[ ] ExceptLog ()
[ ]
[-] do
[-] if IsNull (sVal)
[ ] Print ("No date given")
[-] else
[-] if sVal == FormatDateTime (GetDateTime (), "yyyy-mm-dd")
[ ] Print ("The date is today")
[-] else
[-] if GetDateTimePart ([DATETIME]sVal, DTP_YEAR) == 2006
[ ] Print ("The year is this year")
[-] else
[ ] Print ("Some other year")
[-] except
[ ] ExceptLog ()
[ ]
[-] do
[-] select
[-] case IsNull (sVal)
[ ] Print ("No date given")
[-] case sVal == FormatDateTime (GetDateTime (), "yyyy-mm-dd")
[ ] Print ("The date is today")
[-] case GetDateTimePart ([DATETIME]sVal, DTP_YEAR) == 2006
[ ] Print ("The year is this year")
[-] default
[ ] Print ("Some other year")
[-] except
[ ] ExceptLog ()
[ ]