-
Notifications
You must be signed in to change notification settings - Fork 32
Batch I O Stubbing
Home -> Developer Guide -> Implementation Notes ->
Consistent with the guideline that a unit test or microtest does not touch any files or databases (or indeed any external dependencies of the code under test), Cobol Check removes all I/O-related code from the program under test. As test cases may refer to data items defined in the File Section, Working-Storage Section, Local-Storage Section, or Linkage Section that describe record layouts, we must ensure such data items are accessible to the generated test program at run time.
The Select clause of the File-Control paragraph specifies the internal and external identifiers of each file. It has contents like this:
FILE-CONTROL.
SELECT INPUT-FILE ASSIGN TO INFILE
ORGANIZATION SEQUENTIAL
ACCESS MODE SEQUENTIAL
FILE STATUS INPUT-FILE-STATUS.
SELECT
OUTPUT-FILE
ASSIGN TO OUTFILE
ORGANIZATION SEQUENTIAL
ACCESS MODE SEQUENTIAL
FILE STATUS IS
OUTPUT-FILE-STATUS.
Cobol-check does not need the external identifier, as no actual file I/O will occur during a test run. However, we need to capture the internal name as well as the name of the File Status data item for each file. Test cases may refer to the File Status item to set preconditions, to check expected results, or to specify the behavior of mocks.
When working on the parsing logic, bear in mind the File Status sentence may or may not include the word "is," and may or may not be coded on a single source line. The Select sentence may also be coded across multiple source lines.
In most programs, the File Status item will be coded in the Working-Storage Section of the Data Division. However, in some cases a program may not have a Working-Storage Section, and the File Status item may be coded in the Local-Storage Section. In such cases, cobol-check inserts a Working-Storage Section header and copies the File Status item there.
Storage is allocated for data items coded in the File Section when each file is opened. As we are stubbing I/O operations, the files will never be opened during a test run. Therefore, cobol-check must copy the source lines for any 01-level (and subordinate) data items coded under an FD statement into a part of the program that is guaranteed to have storage allocated at run time.
The File Section may contain entries that look like these examples:
FD INPUT-FILE
. . .
01 INPUT-RECORD PIC X(40).
FD INPUT-FILE
. . .
01 INPUT-RECORD.
05 INPUT-FIELD PIC X(20).
etc.
FD INPUT-FILE
. . .
01 INPUT-RECORD.
COPY INREC.
FD INPUT-FILE
. . .
01 INPUT-RECORD.
COPY INREC REPLACING ==:A:== BY ==IN-==.
FD INPUT-FILE
. . .
01 INPUT-RECORD.
COPY INREC REPLACING ==:A:== BY ==IN-==.
01 ALT-RECORD REDEFINES INPUT-RECORD.
COPY INREC REPLACING ==:A:== BY ==ALT-==.
FD INPUT-FILE
. . .
COPY INREC.
In addition, some programs will use lower-case or mixed-case. Cobol-check must recognize and handle all these variations gracefully.
We copy these definitions into the Working-Storage Section of the generated test program. Storage is allocated for the Working-Storage area when the program is loaded. If the program under test has no Working-Storage Section, cobol-check adds the Working-Storage header.
For recursive programs that have Local-Storage but not Working-Storage, it is safe to add a Working-Storage Section because the purpose of cobol-check is to exercise individual paragraphs. Cobol-check will not run the entire program recursively, so the behavior of a paragraph under test will not be any different when the data items it refers to are located in the Working-Storage Section. The only difference between Working-Storage and Local-Storage is that memory for Local-Storage is allocated separately for each invocation of a recursive program. The program will not be loaded that way during unit test runs.
All batch I/O statements are commented out. The statements are propagated to the generated test program in part to serve as markers for the Generator to match up I/O statements with Mock definitions, and in part so that the user can see the generated source code in case something unexpected happens (or they are just curious).