This module of the Test Harness is primarily involved if there is a data store conversion as part of the migration project, for example, converting VSAM access to DB2. For any given input, the modified program will be demonstrated to produce the identical output as the unmodified version of the program, and follow the same logic path to accomplish that output.

Capture Instrumentation and Execution

I/O testing is similar to business rule testing in that the programs are first instrumented, compiled and executed for capture, and a subsequent replay is performed. 

However, capture execution is significantly different operationally.  During replay, the I/O's modified by the project will be executed against the new data store, not simulated as in Business Rule Replay.  As a result, all data for the database must be secured and coordinated with the execution of the capture, to allow the data to be converted and loaded into the database prior to I/O replay testing.  If the starting state of the database at replay is different from the starting state of the operational data store at capture, the replay will be contaminated with spurious errors and may be unusable. 

Note that only the target data store has to be available during I/O replay.  All other elements of the environment, if relevant, will be supplied by the capture file.  Depending on the particular database, the replay may be able to be executed on Intel workstation, or it may have to be executed on the target platform.

Single Threaded and Multi-Threaded I/O Replay

There are two forms of I/O replay, single-threaded replay and multi-threaded replay.  Single threaded I/O replay requires that the capture be single threaded, and if this condition can be met then the I/O replay is very similar to business rule replay, with the addition of the live I/O's to the data store.  In general, single threaded capture and replay is fairly easy with batch programs, but difficult or impossible with on-line programs.

However, if the capture is multi-threaded, then the replay must also be multi-threaded.  Whereas single threaded I/O replay generates a single executable replay program for each capture file, multi-threaded I/O replay generates a driver program that will invoke each of the relevant data I/O's in temporal sequence, regardless of which program issued them.  None of the other program logic will be executed, only the relevant I/O instruction.

If the migration project generates callable I/O modules for each data table, then the driver will be configured to invoke those modules.  Otherwise, the driver program will be configured to contain one of each I/O construct that occurs across all programs, and that driver program will be subjected to the same conversion process as the application programs themselves. 

The theory behind this design is based on the consistency of automated conversion of I/O constructs.  Each unique I/O command is, in general, converted the same way every time.  Very few are context dependent, and even those few mostly occur during optimization of a converted relational database.  However, if your project is semi-automated or manual, then we strongly recommend that I/O modules be created and implemented as part of the solution..

During multii-threaded I/O replay, the driver will read the specially created I/O replay capture file, and pass data to the appropriate I/O routine, either I/O module or I/O logic within the driver source.  Updates, deletes and inserts to the data table will be executed and the final state compared to the original final state.  For data queries (reads), the returned data will be compared against the originally returned data as well as checking the final state.

If the I/O data capture secured the final state of the data as well as the initial state, then the final state of the test data store can be directly compared to the converted image of the original final state.  In this way, data that was originally unchanged can be proven to be unchanged, so that we can conduct a negative test as well as a positive test.