Software-artifact Infrastructure Repository: Handbook of Java Object Preparation: Java STImpL File Specification

Specifications for STImpL File and Java Make-Test-Script Program

A STImpL file is a file listing your test cases.

We've created a program, java-make-test-script (javamts), which takes a STImpL file (along with other parameters) and creates a script that automatically executes the tests listed in that file.

Note that we implement a "test suite" as a subset (not necessarily proper) of the lines in a STImpL file. So anything that works on a STImpL file should work on a test suite.

This document contains specifications for STImpL files, for the javamts program, and for the scripts that program creates.

Format of a STImpL File.
Each line (string of characters terminated by newline) in the STImpL file represents a test case. For purposes of identifying test cases, we typically consider the first line to represent test case number 1, with numbers advancing sequentially through other lines. There is an exception to this: traces begin with id 0, as do test histories. The kth test is mapped to the (k-1)th trace.
1. Lines in the file (except for the class path setup line) contain one or more parameters; valid parameters and their meaning are as follows (text enclosed in <> stands for values that get put in, all other characters are literal):
  The java-make-test-script creates a C shell script by default, but you can create a Bourne shell script by giving an option when you compile java-make-test-script. All examples in this document are C shell scripts except the II.A.8 -B parameter example.
  
  setenv CLASSPATH <classpath> // for C shell
  CLASSPATH=<classpath> // for Bourne shell
  
  For use in defining class path. <classpath> represents an environmental variable for setting you class path. To run your application program or test drivers, you should set the class path correctly.
  
  -D [<test-driver-name>]
  
  For use in specifying a test driver.
  
  <test-driver-name> represents the name of an executable to be executed. If your script needs different executables for different test cases, then you can supply these as shown above by <test-driver-name>.
  
  For a test script that requires only one executable file, the -D option won't be used in the STImpL file. Instead, an executable file name is given as a parameter to javamts.
  
  -P [<parameter-string>]
  
  For use in supplying parameters.
  
  <parameter-string> represents the string of characters you would type as parameters to the object program for that test case. These will not be "interpreted" in any way by java-make-test-script, that program will simply copy this string verbatim and use it in generating a test script.
  
  Special steps must be followed if you wish to embed the name of some input or output file into a parameter string. See 1.C. below.
  
  For program runs (test cases) that require no parameters, the -P option won't be used in the STImpL file line for that test.
  
  -I [<input-file-name>]
  
  For use in suppling standard-input only.
  
  <input-file-name> represents the name of a file that contains input to the program under test, that will be redirected to the program-under-test using the unix "<" redirection mechanism.
  
  This file name, however, must be a filename relative to the "inputs" subdirectory of the object program. I.e. if your input file is "foo1.dat" and resides directly in the "inputs" subdirectory for "foo" you would write "-I [foo1.dat]. If your input file is "foo1.dat" but you've placed it in a subdirectory of the inputs directory entitled "stdinputs", you would write "-I [stdinputs/foo1.dat]."
  
  For program runs (test cases) that require no standard input, the -I option won't be used in the STImpL file line for that test. There is no default input file.
  
  Note that <input-file-name> must be a string in legal unix filename syntax. In particular it can't contain any "<" characters.
  
  -O [<output-file-name>]
  
  For use in redirecting standard-output only.
  
  <output-file-name> represents the name of a file that will hold standard output of the program under test, that output will be redirected to this file using the unix ">" redirection mechanism
  
  This file name, however, must be a filename relative to the "outputs" subdirectory of the object program. For example if your output file is to be "foo1.out" and is to be placed directly in the "outputs" subdirectory for "foo" you would write "-O [foo1.out]". If your output file is "foo1.out" but you want it placed in a subdirectory of the outputs directory entitled "stdoutputs", you would write "-I [stdoutputs/foo1.out].
  
  When the -O option is omitted, the test script will by default pipe all standard output to the outputs directory, creating a file named tk, where k is an integer representing the test number of this test (the number of the line in the STImpL file that this test case was taken from).
  
  Note that <output-file-name> must be a string in legal unix filename syntax. In particular it can't contain any "" characters.
  
  -F [<name-of-file-to-move>|<name-of-new-file>]
  
  For use in causing output files created by the program to be moved to the official outputs area.
  
  The -O parameter provides a way to specify where standard output should go, and when output files are specified as parameters they are handled in -P. But sometimes a program creates a file with a default name not specified as a parameter. We need to be able to put this file into the outputs directory, potentially under a different name. The -F parameter allows this.
  
  The -F parameter takes two arguments inside the brackets, separated by the "|" character. The <name-of-file-to-move> argument names the file created by the program under test. The <name-of-new-file> names where you want this file moved.
  
  The <name-of-new-file> file name must be a filename relative to the "outputs" subdirectory of the object program. The <name-of-file-to-move> file name must be a filename relative to the "scripts" subdirectory of the object program, where the test is being run from.
  
  For example if you want your output file to be "foo1.out" and to be placed directly in the "outputs" subdirectory for "foo" but your program will be putting it in the current directory (scripts) and calling it lex.yy.c, you would write "-F[lex.yy.c|foo1.out].
  
  At most three -F parameters can occur in a STImpL line, and each will be translated into code to move the named file.
  
  Finally, since this parameter activates a "mv" command, the "file" to be moved could just as well be a directory.
  
  -S [<name-of-startup-script> <params>]
  -X [<name-of-exit-script> <params>]
  
  If the program under test has special requirements it may be impossible to capture them with generic options such as those above. This pair of parameters will allow the tester to create pieces of script that should be executed before and/or after the program-under-test is run.
  
  Either or both of these parameters can be present.
  
  Typically, the <name-of-startup-script> and <name-of-exit-script> arguments each name a file that contains some lines of C shell script. Such filenames must be filenames relative to the "testplans.alt/testscripts" subdirectory of the object program. For example if your script file is to be "test1startup.sh" then it has to be placed directly in the "testplans.alt/testscripts" subdirectory for "foo" and you would write "-S [test1startup.sh]. If your script file is "test1startup.sh" but you want it placed in a subdirectory of "testplans.alt/testscripts" entitled "scripts" , you would write "-S [scripts/test1startup.sh]."
  
  If your script needs parameters of some sort, you can supply them as shown above by <params>.
  
  If you use -S, javamts inserts a line to execute the script you name, just prior to the line that executes the program under test. If you use -X, javamts inserts a line to execute the script you name, just after the line that executes the program under test. So the script written by javamts ends up invoking your scripts directly. You might need to know that in this case, these scripts are invoked as sub-shells, and on termination the environment is restored to its previous state. If that's not what you need, see "-s" and "-x" below.
  
  (Note: there's nothing stopping <name-of-startup-script> and <name-of-exit-script> arguments from naming binaries or executables of other, non-script, sorts, and the <params> as being parameters in those, if those binaries are executables and are in the proper "testplans" subdirectory.)
  
  -s [<name-of-startup-script>]
  -x [<name-of-exit-script>]
  
  These are like -S and -X, except faced with them, javamts physically copies the lines from the named scripts into the script it creates. This may be needed if you need to run some lines that can't be run from a subshell. In this case, you can't use parameters.
  
  There's nothing stopping you from using both -S and -s, and/or both -X and -x, if you use both -S and -s they'll be processed (and result in lines in the script) in order -S, -s and if you use both -X and -x they'll be processed (and result in lines in the script) in order -x -X. (In other words, the -s and -x calls are nested within the -S and -X calls.)
  
  -C [comment]
  
  When present in a STImpL file spec, causes any text appearing inside the brackets to be ignored by java-make-test-script. Comments are used in a STImpL file to specify which STImpL line corresponds to which test frame.
  
  -B
  
  For use in causing executable program to be run as a background job.
2. On each STImpL file line, at least one parameter must be given. Parameters may be listed in any order, all must begin with hyphen followed by a character with no spaces in between them. Zero or more spaces (blanks, not tabs) may appear after the hyphen/character pair, brackets must enclose and delimit the text between them, that text can include anything except for a newline or bracket. Parameters may be separated by zero or more spaces (blanks, not tabs), an end-of-line is interpreted to end the set of parameters, and the entire line cannot exceed 4096 characters (adjustable by changing a constant). Parameters are case-sensitive (-I doesn't mean the same thing as -i).
3. Instructions for naming input and output files in parameter strings.
  1. input files.
    Assume that all tests will be run from the "scripts" subdirectory of the object, i.e. if your object is "calc", then tests will be run from "calc/scripts". We'll generate our automated testing scripts in that directory and that's where we'll run those scripts from. All executable files should reside in the "source" subdirectoty and the class path should be set to access these files.
    
    So, if you want your input files to come from the inputs directory, and need to specify them with parameters, you'd have to specify the path relative to the scripts directory in the parameter list.
    
    Example:
    
    Suppose your program foo opens and reads an input file, and this file is specified in a parameter -i<inputfile>, and suppose for one of the tests of foo you want it to use a file "myinput1.dat".
    
    Suppose you put "myinput1.dat" in a subdirectory of "foo/inputs" called "inputfiles".
    
    Now, if you were running this program by hand on this test from the scripts directory you'd type:
    
    foo -i../inputs/inputfiles/myinput1.dat
    
    So, in your STImpL file spec for this you'd write:
    
    -P [-i../inputs/inputfiles/myinput1.dat]
  2. output files
    There are two ways to get output files into the output directory when specifying them with parameters.
    
    However, only use of the first will support the use, later, of "Runall-and-Diff" (regression testing) scripts.
    1. Write the file to the local directory and include use of the -F option to cause it to be moved.
      So considering the example from C.2.b, you could write:
      -P [-omyoutput1.dat] -F[myoutput1.dat|outputfiles/myoutput1.dat]
    2. You could do as with input files, assuming that the program will be run from "scripts", and that the parameter should be rewritten to redirect the output up to ../outputs/outputfilename
      Example:
      
      Suppose your program foo opens and writes to an output file, and this file is specified in a parameter -o<outputfile>, and suppose for one of the tests of foo you want it to use a file "myoutput1.dat".
      Suppose you want to put "myoutput1.dat" in a subdirectory of "foo/outputs" called "outputfiles".
      
      Now, if you were running this program by hand on this test from the scripts directory you'd type:
      
      foo -o../outputs/outputfiles/myoutput1.dat
      
      So, in your STImpL file spec for this you'd write:
      
      -P [-o../outputs/outputfiles/myoutput1.dat]
      
      But NOTE, as mentioned above, we can't write Runall-and-Diff scripts easily that will use output files written in this manner, so unless there's a good reason, you shouldn't use this approach, and we mention it here only for historical reasons.
Types of scripts created from the above STImpL lines.
There are several types of scripts that could be created from a STImpL file, we describe each here.
1. "Runall" script.
  The purpose of a "runall" script is to execute every test listed in a STImpL file, saving outputs in the outputs directory. To illustrate the possibilities, we provide examples of the various parameters, with STImpL files and the scripts that get created from them if those parameters are used.
  
  Remember that the resulting script is expected to run from the "scripts" directory of the object program. Further, assume that the executable for the object program will be found in the "source" directory with the name foo.
  
  In the following, suppose the object program is "foo.java".
  1. -D parameter.
    For this option, we assume that the executables for the object programs (actually, test driver names) are fooTest.class and fooTest1.class instead of foo.class.
    
    Given STImpL file:
```
setenv CLASSPATH ../source
-D [fooTest]
-D [fooTest1]
```
    A resulting runall script is:
```
The following is an R script type
unsetenv CLASSPATH
setenv CLASSPATH ../source
echo ">>>>>>>>running test 1"
java fooTest >& ../outputs/t1
echo ">>>>>>>>running test 2"
java fooTest1 >& ../outputs/t2
```
    NOTES: since -O wasn't used, default output files are used;
    parameters are put in place after the executable name
  2. -P parameter.
    Given STImpL file:
```
setenv CLASSPATH ../source
-P [1 3 string1]
-P [4 0 string2]
```
    A resulting runall script is:
```
The following is an R script type
unsetenv CLASSPATH
setenv CLASSPATH ../source
echo ">>>>>>>>running test 1"
java foo 1 3 string1  >& ../outputs/t1
echo ">>>>>>>>running test 2"
java foo 4 0 string2  >& ../outputs/t2
```
    NOTES: since -O wasn't used, default output files are used;
    parameters are put in place after the executable name
  3. -I parameter.
    Given STImpL file:
```
setenv CLASSPATH ../source
-I [in17.dat]
-I [idir/in16.dat]
```
    A resulting runall script is:
```
The following is an R script type
unsetenv CLASSPATH
setenv CLASSPATH ../source
echo ">>>>>>>>running test 1"
java foo < ../inputs/in17.dat  >& ../outputs/t1
echo ">>>>>>>>running test 2"
java foo < ../inputs/idir/in16.dat  >& ../outputs/t2
```
    NOTES: since -O wasn't used, default output files are used;
    no parameters are specified in the STImpL file, so none are present in the script;
    input is piped from the input file in the inputs directory
  4. -O parameter with -P.
    Given STImpL file:
```
setenv CLASSPATH ../source
-P [1 3 string1] -O [out1.dat]
-P [4 0 string2] -O [odir/out7.dat]
```
    A resulting runall script is:
```
The following is an R script type
unsetenv CLASSPATH
setenv CLASSPATH ../source
echo ">>>>>>>>running test 1"
java foo 1 3 string1  >& ../outputs/out1.dat
echo ">>>>>>>>running test 2"
java foo 4 0 string2  >& ../outputs/odir/out7.dat
```
    NOTES: -O causes standard output to go where specified;
    parameters are put in place after the executable name
  5. -F parameter with -P.
    Given STImpL file:
```
setenv CLASSPATH ../source
-P [1 3 string1] -F [lex.yy.c|test1out]
-P [4 0 string2] -F [lex.yy.c|test2out]
```
    A resulting runall script is:
```
unsetenv CLASSPATH
setenv CLASSPATH ../source
echo ">>>>>>>>running test 1"
java foo 1 3 string1  >& ../outputs/t1
mv ../scripts/lex.yy.c ../outputs/test1out
echo ">>>>>>>>running test 2"
java foo 4 0 string2  >& ../outputs/t2
mv ../scripts/lex.yy.c ../outputs/test2out
```
    NOTES: since -O wasn't used, default output files are used;
    parameters are put in place after the executable name;
    stdout output is still put into output files;
    unix mv command does the requested file move
  6. -s and -x parameters with (possibly) -P
    Given STImpL file:
```
setenv CLASSPATH ../source
-P [-Dvarname] -s [Sscript1] -x [Xscript1]
-s [Sscript1] -x[Xscript1]
```
    And suppose that files Sscript1 and Xscript1 contain the following:
```
Sscript1:
---------
cp -r ../inputs/setupdirs/sdir1 ./workingdir
cd workingdir

Xscript1:
---------
cd ..
rm -r ./workingdir
```
    A resulting runall script is:
```
The following is an R script type
unsetenv CLASSPATH
setenv CLASSPATH ../source
echo ">>>>>>>>running test 1"
cp -r ../inputs/setupdirs/sdir1 ./workingdir
cd workingdir
java foo -Dvarname  >& ../outputs/t1
cd ..
rm -r ./workingdir
echo ">>>>>>>>running test 2"
cp -r ../inputs/setupdirs/sdir1 ./workingdir
cd workingdir
java foo >& ../outputs/t2
cd ..
rm -r ./workingdir
```
    NOTES: since -O wasn't used, default output files are used;
    parameters are put in place after the executable name on test 1;
    text of startup and exit script files has been placed into the script before and after program foo.class gets executed
  7. -S and -X parameters
    Given STImpL file:
```
setenv CLASSPATH ../source
-S [script1 p1] -X[script2]
```
    A resulting runall script is:
```
The following is an R script type
unsetenv CLASSPATH
setenv CLASSPATH ../source
echo ">>>>>>>>running test 1"
../testplans.alt/testscripts/script1 p1
java foo >& ../outputs/t2
../testplans.alt/testscripts/script2
```
  8. -B parameter
    1. For C shell
      Given STImpL file:
```
setenv CLASSPATH ../source
-P [1 3 string1] -O [out1.dat] -B
```
      A resulting runall script is:
```
The following is an R script type
unsetenv CLASSPATH
setenv CLASSPATH ../source
echo ">>>>>>>>running test 1"
java foo 1 3 string1  >& ../outputs/out1.dat &
```
    2. For Bourne shell
      Given STImpL file:
```
CLASSPATH=../source
-P [1 3 string1] -O [out1.dat] -B
```
      A resulting runall script is:
```
The following is an R script type
unset CLASSPATH
CLASSPATH=../source
export CLASSPATH
echo ">>>>>>>>running test 1"
java foo 1 3 string1  >& ../outputs/out1.dat 2>&1 &
```
2. "Get-traces" script.
  The get-traces script is almost exactly like a runall script. The difference is that it is intended to run an instrumented executable, and after each run, save the trace file created for that executable.
  
  (The get-traces script is set up to run the Sofya trace filter; this tool isn't yet publicly available, but you could substitute another trace gathering utility, and modify javamts to use it.)
  
  The instrumented executable is invoked by sofya.ed.BBTracer, which gathers trace files for that executable. The instrumented executable is given with -D option, which is for supplying a test driver name. We assume that the instrumented executable is "foo.class" in the "objects/foo/source" subdirectory.
  
  Given STImpL file:
```
setenv CLASSPATH ../source:<BCEL>:<sofya>
-D [foo] -P [1 3 string1]
```
  You type:
  
  javamts .. sofya.ed.BBTracer ../testplans/universe T sc.sh instout.tr NULL -B
  
  A resulting get-traces script is:
```
The following is an T script type
unsetenv CLASSPATH
setenv CLASSPATH ../source:<BCEL>:<sofya>
echo ">>>>>>>>running test 1"
java sofya.ed.BBTracer -B foo 1 3 string1  >& ../outputs/t1
cp ${HOME}/.sofyadb/instout.tr ../traces/0.tr
```
  NOTES: <BCEL> is the full path to the location of the BCEL library;
  <sofya> is the full path to the Sofya system directory.
3. "Runall-and-Diff" script.
  The runall-and-diff script is also quite like a runall script. The difference is that after running each test, it compares results of that test with results from a previous run. As such, the script is automating regression testing.
  
  What the script has to do is compare anything created as output by the program with saved versions of outputs. That means it must accomodate 1) files written to standard-output, 2) output files created by the program. It detects the need to do comparisons with these, and the names of files to compare with, by looking in -O and -F parameters.
  
  Because of the similarity of this script with the runall script, we give just one example, with the -P parameter, -O, and -F used. We assume that the executable is "foo.class" in the"objects/foo/source" subdirectory, and that the outputs directory is "/nfs/spectre/u5/mydir/oldoutputs/".
  
  Given STImpL file:
```
setenv CLASSPATH ../source
-P [1 3 string1]  -F [lex.yy.c|test1out]
-P [4 0 string2] -O [odir/out7.dat] -F [lex.yy.c|test2out]
```
  A resulting runall-and-diff script is:
```
The following is an D script type
unsetenv CLASSPATH
setenv CLASSPATH ../source
echo ">>>>>>>>running test 1"
java foo 1 3 string1  >& ../outputs/t1
mv ../scripts/lex.yy.c ../outputs/test1out
cmp -s ../outputs/t1 /nfs/spectre/u5/mydir/oldoutputs/t1
cmp -s ../outputs/test1out /nfs/spectre/u5/mydir/oldoutputs/test1out

echo ">>>>>>>>running test 2"
java foo 4 0 string2  >& ../outputs/odir/out7.dat
mv ../scripts/lex.yy.c ../outputs/test2out
cmp -s ../outputs/out7.dat /nfs/spectre/u5/mydir/oldoutputs/out7.dat
cmp -s ../outputs/test2out /nfs/spectre/u5/mydir/oldoutputs/test2out
```
  NOTES: -O causes standard output to go where specified;
  parameters are put in place after the executable name;
  the output file specified with -O in the second test gets compared with a previous one.
  On the first test, where no -O appears, the "default" output file t1 gets compared with a previous one.
  The output files listed in -F get compared with previous ones.
  The location of old outputs in this example, /nfs/spectre/u5/mydir/oldoutputs/, is something that can be specified when java-make-test-script is run to make the script, but it is assumed that that directory is a saved copy of an outputs directory created on some run of another script, and that the directory has the same structure and filenames in it as will be created by this run of this script.
  
  If the user runs java-make-test-script (see below, section III) with "-d" rather than "-D", the program uses "diff -r" instead of "cmp -s" to do the differencing. This allows comparison of entire output directories.
4. "Runall-and-Diff-Time" script
  The runall-and-diff time script is almost exactly like a runall script. The difference is that it is intended to collect the time taken by each test to run.
  
  Because of the similarity of this script with the runall-and-diff script, we give just one example, with the -P parameter, -O, and -F used. We assume that the instrumented executable is "foo.class" in the "objects/foo/source" subdirectory, and that the outputs directory is "/nfs/spectre/u5/mydir/oldoutputs/".
  
  Given STImpL file:
```
setenv CLASSPATH ../source
-P [1 3 string1]  -F [lex.yy.c|test1out]
-P [4 0 string2] -O [odir/out7.dat] -F [lex.yy.c|test2out]
```
  A resulting runall-and-diff time script is:
```
The following is an D_t script type
unsetenv CLASSPATH
setenv CLASSPATH ../source
echo ">>>>>>>>running test 1"
set t=`mydate`
echo "Start time = ${t}"
java foo 1 3 string1  >& ../outputs/t1
mv ../scripts/lex.yy.c ../outputs/test1out
cmp -s ../outputs/t1 /nfs/spectre/u5/mydir/oldoutputs/t1
cmp -s ../outputs/test1out /nfs/spectre/u5/mydir/oldoutputs/test1out
set t=`mydate`
echo "Finish time = ${t}"

echo ">>>>>>>>running test 2"
set t=`mydate`
echo "Start time = ${t}"
java foo 4 0 string2  >& ../outputs/odir/out7.dat
mv ../scripts/lex.yy.c ../outputs/test2out
cmp -s ../outputs/out7.dat /nfs/spectre/u5/mydir/oldoutputs/out7.dat
cmp -s ../outputs/test2out /nfs/spectre/u5/mydir/oldoutputs/test2out
set t=`mydate`
echo "Finish time = ${t}"
```
  Here mydate is the c program which returns sytem time in seconds (elapsed from 1970) and in fractions of a second with resolution of 1 microsecond.
  
  If the user runs java-make-test-script(see below section III) with "-d_t" rather than "-D_t", the program uses "diff -r" instead of "cmp -s" to do the differencing.
java-make-test-script specification.
java-make-test-script (javamts) is the program that turns a STImpL file into one of the above types of scripts.

To call java-make-test-script, type:
```
javamts  <object-dir> <object-exe> <stimpl-file> <script-type>
            <script-name> <program-suffix> <compare-dir>  <instrument-option> 
```
(The carriage return above is for readability only; all parameters should be given on the single command line.)
<object-dir> : name of object directory for program under test
<object-exe> : name of executable to be executed,
<stimpl-file> : name of STImpL file
<script-type> : R|D|d|T|d_t|D_t

For runall, runall-and-diff using cmp, runall-and-diff using diff, trace, runall-and-diff-time script using diff, or runall-and-diff-time script using cmp
<script-name> : name of output script
<program-suffix> : suffix of program name, or NULL (case insensitive)

-- only for script type T.
<compare-dir> : name of directory containing outputs to compare test outputs to, or NULL (case insensitive)

--only for script type D
<instrument-option> : -B|E|X|C, or NULL (case insensitive)

--only for script type T

It's important to understand how java-make-test-script uses the first two parameters in creating a script. The executable name is the name of the executable that will be run, you could give its full path name, or give a path relative to where you'll be running the script from (the scripts directory).

The contents of the first parameter are more complex: they are prepended to names of input files, output files, scripts, and files-to-be-copied, allowing the script to put things in or get them from the right place. What you put here depends on where you run the script from. Examples will illustrate.

Suppose you have the object "foo" present under the directory structure "/nfs/phantom/u8/goel2/objects/foo" and suppose you'll be running the "java-make-test-script" program from the scripts directory, i.e at path "/nfs/phantom/u8/goel2/objects/foo/scripts".
1. Example:
  Suppose your STImpL file contains:
```
setenv CLASSPATH ../source
-P [1 3 string1]  -I [infile] -F [lex.yy.c|test1out]
-P [4 0 string2] -O [odir/out7.dat]
```
  You type:
```
java-make-test-script .. foo ../testplans.alt/universe
    R sc.sh NULL NULL NULL
```
  This causes java-make-test-script to look for STImpL file "universe" at path "../testplans.alt/universe" relative to the script directory path which is at "/nfs/phantom/u8/goel2/objects/foo/scripts", so javamts finds the STImpL file at "/nfs/phantom/u8/goel2/objects/foo/testplans.alt/universe, and writes a runall script sc.sh looking like this:
```
echo script type: R
unsetenv CLASSPATH
setenv CLASSPATH ../source
echo ">>>>>>>>running test 1"
java foo 1 3 string1 < ../inputs/infile  >& ../outputs/t1
mv ../scripts/lex.yy.c ../outputs/test1.out
echo ">>>>>>>>running test 2"
java foo 4 0 string2  >& ../outputs/odir/out7.dat
```
  NOTES: java-make-test-script has taken your first parameter, "..", and used it in writing where infile and outputs are (e.g. writing "../inputs/infile" on test 1)
2. Example:
  Suppose you have the same STImpL file, and you type:
```
java-make-test-script /nfs/phantom/u8/goel2/objects/foo
java foo ../testplans.alt/universe R sc.sh NULL NULL NULL
```
  This causes java-make-test-script to look for STImpL file "universe", and write a runall script looking like this:
```
echo script type: R
unsetenv CLASSPATH
setenv CLASSPATH ../source
echo ">>>>>>>>running test 1"
java foo  1 3 string1 < /nfs/phantom/u8/goel2/objects/foo/inputs/infile >& /nfs/phantom/u8/goel2/objects/foo/outputs/t1
mv /nfs/phantom/u8/goel2/objects/foo/scripts/lex.yy.c /nfs/phantom/u8/goel2/objects/foo/outputs/test1.out
echo ">>>>>>>>running test 2"
java foo  4 0 string2 >&
/nfs/phantom/u8/goel2/objects/foo/outputs/odir/out7.dat
```
3. Example:
  Suppose your STImpL file contains:
```
setenv CLASSPATH ../source
-D [fooTest] -P [1 3 string1]  -I [infile] -F [lex.yy.c|test1out]
-D [fooTest1] -P [4 0 string2] -O [odir/out7.dat]
```
  You type:
```
java-make-test-script .. null ../testplans.alt/universe
    R sc.sh NULL NULL NULL
```
  This causes java-make-test-script to look for STImpL file "universe" at path "../testplans.alt/universe" relative to the script directory path which is at "/nfs/phantom/u8/goel2/objects/foo/scripts", so javamts finds the STImpL file at "/nfs/phantom/u8/goel2/objects/foo/testplans.alt/universe, and writes a runall script sc.sh looking like this:
```
echo script type: R
unsetenv CLASSPATH
setenv CLASSPATH ../source
echo ">>>>>>>>running test 1"
java fooTest 1 3 string1 < ../inputs/infile  >& ../outputs/t1
mv ../scripts/lex.yy.c ../outputs/test1.out
echo ">>>>>>>>running test 2"
java fooTest1 4 0 string2  >& ../outputs/odir/out7.dat
```
  NOTES: java-make-test-script has taken your first parameter, "..", and used it in writing where infile and outputs are (e.g. writing "../inputs/infile" on test 1). Since the STImpL file has -D option, the second parameter of java-make-test-script is ignored (here, null is given, but any name can come).
4. Example:
  Suppose your STImpL file contains:
```
setenv CLASSPATH ../source:<BCEL>:<sofya>
-D [foo_1] -P [1] -I [infile]
-D [foo_2] -P [4 0] -O [odir/out.dat]
```
  You type:
```
java-make-test-script .. sofya.ed.BBTracer ../testplans/universe
    T sc.sh instout.tr NULL -B 
```
  This causes java-make-test-script to look for STImpL file "universe" at path "../testplans.alt/universe" relative to the script directory path which is at "/nfs/phantom/u8/goel2/objects/foo/scripts", so javamts finds the STImpL file at "/nfs/phantom/u8/goel2/objects/foo/testplans.alt/universe, and writes a gettraces script sc.sh looking like this:
```
echo script type: T
unsetenv CLASSPATH
setenv CLASSPATH ../source:<BCEL>:<sofya>
echo ">>>>>>>>running test 1"
java sofya.ed.BBTracer -B foo_1 1 < ../inputs/infile >& ../outputs/t1
cp $HOME/.sofyadb/instout.tr ../traces/0.tr
echo ">>>>>>>>running test 2"
java sofya.ed.BBTracer -B foo_2 4 0 >& ../outputs/odir/out7.dat
cp $HOME/.sofyadb/instout.tr ../traces/1.tr
```
  NOTES: <BCEL> is the full path to the location of the BCEL library;
  <sofya> is the full path to the Sofya system directory.
5. Example:
  Suppose your STImpL file contains:
```
setenv CLASSPATH ../source/src:../source/junit
-P[de.susebox.java.util.TestTokenizerProperties]
-P[de.susebox.java.util.TestTokenProperties]
```
  You type:
```
java-make-test-script .. junit.textui.TestRunner 
    ../testplans.alt/v0/universe.junit R sc.sh NULL NULL NULL
```
  This causes java-make-test-script to look for STImpL file "universe.junit" at path "../testplans.alt/v0/universe.junit" relative to the script directory path which is at "/nfs/phantom/u8/goel2/objects/foo/scripts", so javamts finds the STImpL file at "/nfs/phantom/u8/goel2/objects/foo/testplans.alt/v0/universe.junit", and writes a runall script sc.sh looking like this:
```
echo script type: R
unsetenv CLASSPATH
setenv CLASSPATH ../source/src:../source/junit 
echo ">>>>>>>>running test 1"
java junit.textui.TestRunner de.susebox.java.util.TestTokenizerProperties  > ../outputs/t1 2>&1
echo ">>>>>>>>running test 2"
java junit.textui.TestRunner de.susebox.java.util.TestTokenProperties  > ../outputs/t2 2>&1
```