| Overview of Testing | Initial Values | |
This chapter explains what a fragment is. It also describes how to use TouchPoint to define a section of COBOL code as a fragment.
TouchPoint works on code fragments: these are significant pieces of code which you define by using a TouchPoint wizard to specify their start and end lines within your source code. You could define the following COBOL extract, for example, as a fragment:
MOVE 0 TO VALUE-TOTAL DATE-COUNT
MOVE 1 TO ARRAY-INDEX
PERFORM UNTIL ARRAY-INDEX > ARRAY-COUNT
MOVE DATE-ARRAY(ARRAY-INDEX) TO CURRENT-RECORD
IF CURRENT-YY = REQUIRED-MONTH-YY
AND CURRENT-MM = REQUIRED-MONTH-MM
ADD 1 TO DATE-COUNT
ADD CURRENT-VALUE TO VALUE-TOTAL
END-IF
ADD 1 TO ARRAY-INDEX
END-PERFORM
CONTINUE.
When you use TouchPoint to define a fragment, it returns a list of all
the data items contained within that section of code. From the example
above, the following would be returned: ARRAY-COUNT, ARRAY-INDEX,
CURRENT-MM, CURRENT-RECORD, CURRENT-VALUE, CURRENT-YY, DATE-ARRAY
(ARRAY-INDEX), DATE-COUNT, REQUIRED-MONTH-MM, REQUIRED-MONTH-YY,
and VALUE-TOTAL.
You can define each data item returned by TouchPoint as:
How you define a data item depends on the way it is used within the
fragment. In the above fragment, for example, records are being read, one
at a time, from DATE-ARRAY and then two of the fields within
DATE-ARRAY (CURRENT-YY and CURRENT-MM)
are compared to REQUIRED-MONTH-YY and REQUIRED-MONTH-MM.
If the values match, the data-items DATE-COUNT and VALUE-TOTAL
are incremented. If you wanted to test this piece of code, therefore, you
could feed new values into REQUIRED-MONTH-YY and REQUIRED-MONTH-MM
and monitor the values output in DATE-COUNT and VALUE-COUNT.
In order to use TouchPoint to automate this testing process, you would
need to define REQUIRED-MONTH-YY and REQUIRED-MONTH-MM
as input variables and DATE-COUNT and VALUE-COUNT
as output variables.
The most effective way of testing code fragments is to use fragment testing. This is the process of repeatedly executing a single fragment in isolation from the rest of the program, whilst varying the contents of its input variables. To do this, TouchPoint needs to be able to begin execution at the start of the fragment without having to execute the rest of the application code up to that point. It also needs to be able to set meaningful values for all of the data items used within the fragment. These values can be supplied by TouchPoint itself. Known as initial values, they can be generated by using TouchPoint to run the application and store a value for each data item in the fragment, or they can be entered manually. When you run a fragment test, however, not all data items use initial values. You can enter the values to be used for all those data items that you have defined as input variables. You can supply multiple values for an input variable - the fragment is executed once for each value that you supply. Each time a fragment test is run the contents of the fragment's output variables are recorded. Analyzing these output variable values can highlight discrepancies and exceptions in fragment execution.
In order to repeatedly execute a single code fragment, TouchPoint must be able to reset the state of the program to the start of the code fragment. This means that not all code fragments can be tested in this manner. For example, if a piece of code writes to a file, it is not possible to undo the write operation before executing the code for a second time. Fragments that can be reset and executed repeatedly are termed closed fragments, while those that cannot are termed open. If a fragment contains any of the following operations, it is open:
If control returns to the fragment after execution of a GO TO or CALL statement, the fragment is not considered open, provided that the called code does not contain anything that makes it open. TouchPoint flags GO TO and CALL statements within a fragment, therefore, but allows you to decide whether the fragment is open or closed.
Open fragments cannot be tested using fragment tests but only by executing the entire application, that is, by using application tests.
An application test can be run against one or more, open or closed, fragments. It is the only method by which open code fragments can be tested. An application test works by running the entire application. You cannot enter input variable values for an application test. Output variables are recorded for each fragment under test every time that fragment is encountered.
A code fragment has a start and an end line within the source, a set of input variables and a set of output variables. (A single data item can be defined as both an input and an output variable).
You can define any section of code as a fragment, although normally a fragment will perform a significant function and is a piece of code that either:
When you select the lines of code that comprise a fragment, you should not select any of the following at either the start or the end of the fragment:
Comment lines and section and paragraph names are invalid because a
fragment must start on an executable line. A fragment cannot end with an
END-IF statement because, given an IF, ELSE, END-IF
construct, the END-IF statement will never be executed if
the condition is true. A fragment cannot end with an END-PERFORM
statement because the PERFORM loop would only be executed
once.
If you do select any of the above, TouchPoint displays a warning message and you can choose to let it redefine the fragment such that the invalid statements are no longer included.
A warning is also displayed if you select, as the last line of a
fragment, a statement that may not be executed when a fragment test is
recorded or run (for example, the ELSE clause of an IF, ELSE,
END-IF construct). The message displayed by TouchPoint offers you
the option of altering the fragment definition so that it no longer ends
on this statement. If you choose to ignore this warning a message is also
displayed, if the statement is not executed, when the fragment test is
recorded and when it is run. You can choose to ignore this warning and
record the test data or you can choose to ignore any test data. In this
case, "not encountered" is displayed in place of the test data
at the analysis stage.
There are two types of fragment:
Closed fragments have no external dependencies. They can be executed repeatedly using any number of input variables. You can run fragment tests and application tests on a closed code fragment.
Open fragments contain external references, such as file or database I/O, or system calls to CICS or IMS. An open fragment cannot be executed repeatedly as its state cannot be reset in isolation and so it can only be tested using application tests.
You can use TouchPoint to define data items used by a code fragment as input variables.
For a fragment test, you can specify multiple values for each input variable. The test is repeated once for each value that you specify. You can specify input variable values in any of the following ways:
Note: You cannot specify input variable values for application tests.
As well as input variables, you can define data items used by a code fragment as output variables. If you define a data item as an output variable, its value is recorded when the last line of the fragment is executed and stored for later analysis.
You can use TouchPoint to run a test, and record the value of a fragment's output variables, before you make any changes to your code. This records a baseline - the value of any output variables that you have defined. You can then perform regression testing by comparing the baseline to the results obtained from running the same tests, after you have made the changes to your code.
For fragment tests only, you can also use a baseline to perform conformance testing by manually editing the baseline to create a set of expected results.
To create a fragment, open your application project and then select New from the Fragment menu. The dialog box shown in Figure 20-1 is displayed.
Figure 20-1: Creating a Fragment
The code fragment name is blank unless you have selected one or more lines within a program that is open for editing, in which case the default code fragment name of program-name_n is displayed. You must enter a fragment name, or use the default supplied by TouchPoint. You do not have to enter a description, but it is advisable to do so as this will make it easier to identify the fragment later, when you have created many more. For the same reason, it is a good idea to give the fragment as meaningful a name as possible.
You can enter manually the program name and the line numbers (these are the sequence numbers used within the editor) at which the fragment starts and ends, or you can open the appropriate .cbl file for editing, select the section of code that comprises the fragment and click on the Use current selection button.
Once you have named the fragment and specified the lines of code that comprise it, click Next. The specified code is parsed:
If any of the following operations are contained within the fragment, the fragment must be considered open:
If control returns to the fragment after execution of a GO TO or CALL statement, the fragment is not considered open. TouchPoint flags GO TO and CALL statements within a fragment, therefore, but allows you to decide whether the fragment is open or closed.
If the fragment contains any of the operations listed above, the dialog box shown in Figure 20-2 is displayed.
Figure 20-2: Open Fragment
From here you can:
Note: You cannot create fragment tests for open fragments.
You must define at least one output variable for a fragment. In addition, for fragment testing, you must define at least one input variable. The dialog box shown in Figure 20-3 enables you to define input and output variables.
Figure 20-3: Defining Input and Output Variables
Data items used within the code fragment can be defined as input and/or output variables. An input variable is a data item for which you can specify one or more values when running a fragment test. An output variable is a data item whose value is recorded when a test is run.
A list is displayed of all the data items used within the fragment. For each data item, the way it is used within the fragment (used or modified) and its picture clause are displayed.
You can opt to display any related data by clicking on the Show Related Data button. Related data items are those data items within an original data item's structure which can affect its contents. These data items have Related displayed under Fragment Usage.
You can define any of the displayed data items as input variables or output variables. It is perfectly acceptable to define a data item as both an input and an output variable.
To define a data item as either an input or an output variable, select it and then click on the Add button beneath the text Input variables or Output variables as appropriate. You can remove a data item from the list of input or output variables by selecting it within that list and clicking Remove. You can select multiple data items within the complete list (simply hold down the Ctrl key as you click on each data item) and you can de-select them by clicking on them a second time. When you are happy with your choice of input and output variables, click Next.
If the fragment you are defining is open, an additional button, Add Program Data appears on the Define Input and Output Variables dialog box. Click this button to display the dialog box shown in Figure 20-4.
Figure 20-4: Adding Program Data
You can enter the name of any data item used by the program and add it to the list of data items by clicking OK. Click the Browse button to display a list of every data item in the program's Working-Storage Section.
Note: For an open fragment, you cannot use fragment testing and you cannot, therefore, specify values for the input variables that you define. However, the values of any input variables that you define are recorded when you run an application test, and are displayed on the Analyze Application Test dialog box.
For closed fragments only, the Initial Value Creation dialog box is displayed, as shown in Figure 20-5.
Figure 20-5: Initial Value Creation
From here you can:
You can defer the creation of initial values until later. See the chapter Initial Values for details.
This is the default option so simply click on the Finish button to create your fragment.
You can create a set of default initial values. See the section Default Initial Values.
You can generate initial values by executing the application. See the section Generating Initial Values.
To define a set of default initial values:
Figure 20-6: Default Initial Values
To generate a set of initial values by executing the application:
Figure 20-7: Generate Initial Values by Execution
You can check that your code fragment has been created by clicking on the Tests tab on the Project View. The new fragment is shown beneath the name of the .cbl file and underneath the appropriate heading, Open Code Fragments or Closed Code Fragments as shown in Figure 20-8.
Figure 20-8: Displaying Code Fragments
The number in parentheses, to the right of the fragment name, is the number of tests that have been created for the fragment.
Once you have created a fragment, you can edit the fragment definition and alter any of the following:
You can alter the description of the fragment.
You can alter the start and end line of the fragment, either directly or by selecting the code from within the editor and clicking Use current selection.
You can add or remove input variables.
You can add or remove output variables.
To edit a fragment definition:
Figure 20-9: Editing a Fragment Definition
You can display the source code that comprises a fragment:
Figure 20-10: Displaying a Fragment
You can alter the way in which a fragment is displayed:
To delete a fragment:
This removes the fragment definition from the TouchPoint database. It does not delete any code.
Copyright © 1999 MERANT International Limited. All rights reserved.
This document and the proprietary marks and names
used herein are protected by international law.
| Overview of Testing | Initial Values | |