T-Plan Robot Documents > T-Plan Robot Enterprise v2 Tutorial

Scripting overview

T-Plan Robot is in fact a scriptable desktop viewer which follows instructions from a test script to reproduce user actions on the desktop. Test scripts may be of three formats:
  • Proprietary scripting language test scripts. We will call them ordinary or regular scripts in the following topics. The language is simple, text-based and close to spoken English and thus easy to understand. You have already seen a trivial test script of this format in the "Hello world!" example topic. A complete scripting language specification is available in the T-Plan Robot Enterprise documentation. Such test scripts are intended to be saved as plain text files with the .tpr extension (recommended). As test scripts are interpreted by the T-Plan Robot scripting engine, you have to start the tool and pass the script through the CLI or open it in the GUI in order to execute it.
  • Java test scripts. There is a Java Test Script API allowing to write and execute test scripts in the Java language. This is very convenient for integration with data sources and additional technologies, for example for loading of test data from database or a file. As T-Plan Robot is internally able to compile Java source code and execute it on the fly, you may use Java test scripts the same way as the proprietary ones and manage them both through the CLI and GUI (as long as they have have the .java file extension). Java test scripts may also act as standalone programs (having their own main() method) and they may be instantiated and executed from third party applications.
  • Hybrid test scripts (Enterprise version 2.1/2.2 and higher) are ordinary scripts which call Java code either by running of Java test classes or calling Java code directly through embedded Java code blocks. These two mechanisms will be discussed in the Interoperability of scripts and Java code later on.
It is important to realize that both test script formats support the same set of commands (user actions) specified by the scripting language specification. Most scripting language commands have their counterpart methods in the Java API and there's even a way to convert ordinary scripts to Java code (will be discussed later on). That is why you should use the language specification as a reference even if you decide to develop your test suite or its part in Java.

The following example shows the "Hello world" code example with a corresponding test script in Java.

Type "Hello world!"
import com.tplan.robot.scripting.DefaultJavaTestScript;
import com.tplan.robot.scripting.JavaTestScript;

import java.io.IOException;

public class Hello extends DefaultJavaTestScript implements JavaTestScript {
public void test() {
try {
type("Hello world!");
} catch (IOException ex) {

One of the frequently asked questions is what is better, ordinary scripts or Java? Well, it depends. Someone favors ordinary scripts, someone Java programming and others prefer to mix these approaches to mix these two formats through the hybrid mechanisms. There are advantages and disadvantages:
  • Ordinary test scripts are great for fast and simple automation. The GUI provides many features allowing easy writing, debugging and maintenance of scripts, such as command and snippet wizards, record & replay, syntax highlighting, breakpoints, step-by-step execution and many more. See the Script Editor help topic for an overview of all features. The scripting language however suffers from many limitations and it may not suffice in complex automation scenarios.
  • Java test scripts are more flexible. The Java language is very advanced and allows constructions which are not supported by the limited proprietary scripting language. It is also possible to leverage any functionality delivered by third party Java libraries in the test code, for example loading of test data from external sources like relational DB , Excel sheets, CSV files or XML. A good overview of Java script advantages is also in the Developing Java Test Scripts help topic.