Browse Prior Art Database

Component Test Aid

IP.com Disclosure Number: IPCOM000089312D
Original Publication Date: 1977-Oct-01
Included in the Prior Art Database: 2005-Mar-04
Document File: 2 page(s) / 14K

Publishing Venue

IBM

Related People

Norris, JB: AUTHOR

Abstract

When testing computer programs that involve a string of modules, there is a stage between module test (smallest testable entity) and full functional test (as a user sees it) that can use more testing aids. Many tools are available for module testing. Full functional tests can be created from the External Functional Specifications. This paper describes a Component Test Aid (CTA) which is used when testing a subset of the modules contained in the function.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 52% of the total text.

Page 1 of 2

Component Test Aid

When testing computer programs that involve a string of modules, there is a stage between module test (smallest testable entity) and full functional test (as a user sees it) that can use more testing aids. Many tools are available for module testing. Full functional tests can be created from the External Functional Specifications. This paper describes a Component Test Aid (CTA) which is used when testing a subset of the modules contained in the function.

To help define the problem, here is an example of the existing gap. Module A invokes module B which conditionally invokes module C or D. A different programmer is responsible for each module. The programmer designing A knows the interface to B. The programmer designing B knows the interface to A, C and D. Programmer A does not necessarily know the interfaces between B and C; nor that between B and D; nor does he know the conditions under which B invokes C or D.

Given this situation, when programmer A has finished module test and wants to test his interface to B, he creates a test case, runs it, and receives the output of the run. Often he does not know how to interpret the output for successfulness of the test since he doesn't necessarily know what to expect from modules B, C and D.

CTA is a simple test tool which generates information that is helpful when analyzing the successfulness of a component test run. CTA, though used by the programmer responsible for the invoked module, is for the benefit of testing the invoking module. The programmer responsible for the invoked module knows the minimum set of I/O operations and the minimum set of mandatory routines that must be exercised in order to consider that his module has been successfully executed. CTA requires this programmer to describe the minimum set of operations via test macros. The five CTA macros are: CTAENT - An entry point identifier. CTAIPR - An input file read point identifier. CTAOPW - An output file write point identifier. CTARTX - A routine execution point identifier. CTAEXT - An exit point identifier.

When his program is executed, CTA will generate messages which clearly inform the submitter of the test run that fundamental operations were or were not executed. The entry macro has the form: CTAENT Module-Name, Entrypoint- Name

The entry macro should be placed at the entry point in the module. If there is more than...