background image
<< Multi-Application Testing | Multi-Application - Testcase structure in a multi-application environment >>
Multi-Application - Multi-application startup and recovery
<< Multi-Application Testing | Multi-Application - Testcase structure in a multi-application environment >>
382
User's Guide
22 M
ULTI
-A
PPLICATION
T
ESTING
Multi-application startup and recovery
Multi-application startup and recovery
The essential difference between single-application and multi-application
testing is clearly the difference between "one" and "many." When the
following entities in a testcase are greater than one, they need special
consideration and support functions found in SilkTest:
Agent names
Application main window names
Sets of application states associated with each main window name
Multi-machine testing requires that you map both the name of an application
and all application states for that application to the machine on which it will
be tested. This makes it possible for you to direct test operations to the right
machines, and it enables SilkTest to automatically set the machines to the
proper application state before a test is run and to clean up after a test has
failed.
Testcase structure in a single-application environment
The code that implements a testcase for a single application is similar to that
of a testcase for applications on multiple separate machines in a client/server
environment. This section summarizes the structure of the single-application
version and some SilkTest components used to implement it. You can
compare the structure with the support code needed for running multiple
applications, which is described later in this chapter.
defaults.inc
The defaults.inc file is provided by SilkTest and implements the recovery
system for a single application test. That is, it contains the DefaultBaseState
function that performs any cleanup needed after an operation under test fails
and returns the application to its base state.
You can define a base state function to replace the DefaultBaseState function
by defining an application state without using the basedon keyword. This
creates an application state that 4Test executes instead of the
DefaultBaseState function.
The defaults.inc file contains four other functions that 4Test automatically
executes unless you define functions that replace them:
DefaultScriptEnter -- a null function, allows you to define a ScriptEnter
function, as discussed below.