PTD provides the capability to use pre- and post-processor scripts to prepare the environment for suite or testcase execution and to process the output.

Preprocessor scripts are run directly before the suite or testcase, and postprocessor scripts are run directly after the suite or testcase. Processor scripts are run like any other Phantom script. They support all Phantom functions and variable types. In addition, processor scripts have access to a special variable type called 'ptdoutput'. Using this variable, the script has access to the PTD output and other PTD functions.

In this tutorial, the basic features of a processor script will be explored. The tutorial will use the 'tutorial.pws' workspace created in the first tutorial.

Begin by opening the 'postprocessor.psc' script included in the 'scripts' directory where PTD was installed. This script is a sample postprocessing script included for this tutorial.



The script starts with a 'try-catch' statement. The 'try' portion tries to create a 'ptdoutput' variable (P) and assign to it the default 'PTDOutput'. The 'PTDOutput' variable is a 'ptdoutput' automatically added to the script by PTD when the script is run as a processor. If the script is not run as a processor, the ptdoutput variable type will not exist, nor will the 'PTDOutput' variable. The 'try-catch' statement catches the error that would be produced and throws a new error explaining that the script must be run as a processor.

The script then continues on to do the actual processing. This script will check to see if the PhantomTarget application is still running. If it is, the assumption is an error occurred in a previous script, so this script tries several times to close PhantomTarget. If it cannot successfully close PhantomTarget, it will throw an error, indicating that the problem is with the PhantomTarget application (it is 'frozen').

The script then uses the 'getErrorCount()' ptdoutput method to get the total errors that were created by the suite or testcase this postprocessor is associated with. If this processor is used with a suite, this method returns the sum of the errors of all subsuites and testcases contained in the suite.

Finally, the processor uses ptdoutput's 'saveAsHTML' method to save the output associated with this suite or testcase to a HTML file. This saves only the output associated with the suite or testcase associated with the processor, not the output of any parent or sibling suites or testcases. If the processor is associated with a suite, then this saves the output of the suite and all subsuites and testcases contained within the suite.

The processor script will now be applied to the 'Tutorial' root suite in the 'tutorial.pws' workspace. If the 'tutorial.pws' workspace is not open in PTD, do so now.

Select the 'Tutorial' root suite. The properties of the suite should appear in the properties panel. The properties include a field for a Preprocessor and a Postprocessor. A postprocessor will be added to this suite. Click the '...' button next to the Postprocessor field. A dialog will open. Navigate to the 'scripts' directory where PTD was installed, and select the 'postprocessor.psc' script, and click 'Open'. The script path will be added to the postprocessor field. Click the 'Apply' button, then save the suite.



The suite should have a 'Hello World' testcase and a 'Hello Phantom' testcase. If it does not, add them now as described in the first tutorial.

Run the suite. Both testcases should run normally without errors (recall that the 'Hello Phantom' testcase will request an input). At the end of the run, the postprocessor will run. The output of the postprocessor will appear in the output panel for the suite. In this case, the postprocessor did not have to do anything because PhantomTarget closed properly. Therefore, the postprocessor only displayed the total error count (0) and saved the output to the HTML file (note: the HTML file is saved to the directory where PTD is installed if a full path is not entered as the parameter to the saveAsHTML method).



To see the processor in action, an error must be introduced in the 'Hello Phantom' testcase script. Open the script associated with the 'Hello Phantom' testcase. After the 'System("..\\PhantomTarget.exe")' command, add the following lines:

exception e;
e.SetError("Sample Error");
e.throw();



This will throw an error and will stop the execution of the script, leaving PhantomTarget open. Save the script and run the 'Tutorial' suite.



Notice that in the output, an error was generated in the 'Hello Phantom' section. PhantomTarget was not closed by the 'Hello Phantom' script, but was closed by the postprocessor. The postprocessor also displayed an error count of '1', since an error occurred in the 'Hello Phantom' testcase.

This tutorial gave a brief overview of how to use processors. In a similar manner, the run environment can be managed to ensure that each testcase starts with a clean environment. Also, preprocessor scripts can be run to prepare the environment for a testcase or suite by opening applications, copying files, or setting initial states. Since the scripts use the Phantom language and have access to the entire Phantom function set, processors provide a very flexible and robust way to manage the run environment.