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.
hello.tpr
|
|
Hello.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) { ex.printStackTrace(); } } }
|
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.
|