Creating Structure: Steps and Scripts

Tests in the software engineering industry usually consist of test cases. A test case is either a single logical step or a sequence of steps aimed at testing of a feature, functionality or correct behaviour of an application. An expected result is usually defined. Test cases are often referred to as test scripts and they are usually collected to test suites. 

T-Plan Robot Enterprise supports test cases (called "scripts" in T-Plan terminology) and steps. It is expected that test suites are managed on a higher level outside of T-Plan Robot, such as through the test management tools like T-Plan Professional. The scripting language contains two commands, Script and Step: 

• Script labels either start or end of a script and associates it with a name or ID. It is intended to be used in pairs of [ "Script <id>start", "Script <id>end"] to define a block of code which executes a particular test case. Any output objects generated inside such a block (screen shots, steps or warnings) are then associated with the script ID and this relationship is reflected in the test result XML data. Script result is pass if all steps it contains pass. As a script block validity ends automatically with the file end or with declaration of another script start, declaration of the script end is optional and may be omitted. The "start" keyword may be omitted as well and the command can be defined as simple as "Script <id>". 
• Step defines result of a test step. It represents one atomic instruction of a script (test case). Steps should be located inside a block labeled by the Script command. Steps should be defined to deliver a partial result, in general after a sequence of commands which automate the instruction. Steps are identified by a mandatory name and support a wide range of optional parameters, such as step result, instructions, expected and actual result descriptions and notes. 

Script and step structures are reflected both in HTML and XML reports created through the Report command. The XML serves as test report viewable through a web browser as well as a source of test result data suitable for export to 3rd party applications. Reporting functionality will be discussed in details later on in this tutorial. 

As an example let's add the script and step structure to the calculator example from previous topic. We suppose that it automates two test cases: verify calculation of "5+5" (script 1) and "10*5" (script 2). For simplicity the steps always returns "pass" because we do not verify the result in any way. Verification of application behaviour is covered extensively in the next chapter of this tutorial. 

# Define the OS variable because the library expects it. 
Var OS="Windows" 

# Include the library. 
Include calculator-lib. tpr

# Define XML report. 
Report calculator-{OS}.xml desc="Calculator testing on {OS}."

# Calculate "5+5" and"10*5". 
Script 1 name="Calculate 5+5"
calculate "5+5" 

Script 2 name="Calculate 10*5"
calculate "10*5" 

# Variable initialization based on target OS. 
# If the "OS" variable is not initialized, default to Windows. 
Var RUN_BOX_KEY="Windows+r"
Var CALCULATOR_CMD="calc" 

# Both systems close applications through Alt+F4 
Var CLOSE_KEY="Alt+F4" 

if ("{OS}" == "Linux") { 
  Var RUN_BOX_KEY="Alt+F2"
  Var CALCULATOR_CMD="gnome-calculator"
} 

# Start an application through the Run box. 
# Params: {1} ... application start command 
procedure startApp { 
  Press "{RUN_BOX_KEY}" wait=5s
  Typeline "{1}" wait=4s
} 

# Start the calculator, type the expression, save 
# a screenshot to a uniquely named file and close it. 
# Params: {1} ... numeric expression to type, for ex. "5+5" 
procedure calculate {
  startApp "{CALCULATOR_CMD}" 
  Step "Start" instruct="Start calculator" result="pass"
  Typeline "{1}" wait=2s
  Screenshot calculator_{_CURTIME}.jpg desc="Result of {1}" 
  Step "Calculate" instruct="Calculate {1}" result="pass"
  Press "{CLOSE_KEY}" wait=2s
  Step "End" instruct="Close calculator" result="pass"
}