Method for testing system components of an object-oriented program

[0002] 1. Field of the Invention

[0003] The present invention is directed to a method for testing system components of an object-oriented program wherein arbitrary methods are replaced by stubs and a test frame generator generates stubs that have the same call and return parameters available to them as a function being replaced for simplified testing purposes.

[0004] 2. Description of the Prior Art

[0005] Criteria for the comparison of methods, particularly comparative methods of different presentation possibilities of an object-oriented program are explained in W. Archert, “Objektorientiert analysieren—Ein Übeblick der wichtigsten Methoden”, Electronik 3/96, pages 80-86. Further, advantages of object-oriented programming are presented, particularly with regard to modularity and portability.

[0006] In the development of a software system, it is meaningful to test the individual system components in isolation before the test of the overall system. For example, individual program modules or—given an object-oriented development—classes are system components. The problem often arises in the class or module test that a test unit (class or, respectively, module) is highly dependent on other test units. Such dependencies derive, for example, from the mutual employment of functions (or methods, given the employment of classes). The result thereof, however, is that all other test units U that are used by A (directly or indirectly because, for example, U in turn uses other units) must already be present for the test of a test unit A.

[0007] Accordingly, an object of the present invention is to simplify and speed up the testing of such test units.

[0008] In order to avoid this problem, the present invention produces substitute functions with a dummy functionality for the functions and/or methods from other test units U used by the test unit A. Such substitute functions are also called “stubs”. Even when a function/method is already implemented, it can be meaningful for the test of other functions/methods to replace this with a stub.

[0009] As a result thereof, the complexity of the test frame can be kept low.

[0010] The present invention describes the automatic generation of a minimum set of complete substitute functions (stubs) for employment in the class and/or module test. What is thus meant is that all functions/methods that are declared in the software but whose implementation is either not yet present or, on the other hand, cannot be used for complexity reasons are automatically implemented as substitute functions (stubs). Care is thereby exercised that both the return parameter and the handover parameter of the function/method are generated equivalent to the original function/method for the substitute function. A test frame class is locally instanced in the function/method for the implementation of the substitute function. This test frame class encapsulates an automatic status unit that is defined by the parameters (both return handover parameters) of the function that is replaced by the stub. When farther-reaching logical operations are to be implemented within the stub, this can be manually supplemented.

[0011] When the software system begins the test run, a branch is made in the stub according to the preset mode of the test frame class. For example, the mode can be that interactive commands corresponding to a command set of an interpreter integrated in the test frame class are allowed at a command prompt or a command datafile that, for example, generates outputs according to the command of the command datafile is implemented in the substitute function. After the interaction or, respectively, the execution of the command datafile, a branch is made from the substitute function back into the calling module. As soon as it is called, a further substitute function makes the same functionality available with the parameters it has. Thus, specific tests can be implemented for all substitute functions with the one test frame class. The encapsulation of the test frame class as a separate automatic status unit enables the flexible employment in every substitute function. The test frame class instanced for the substitute function is initialized with parameters (both handover and return parameters). Type-specific operations that are interactively called or called from a command datafile can be defined, therefore, in the test frame class.

[0012] An advantageous development of the inventive method is sound in the interactive employment of the test frame class. This interaction represents a function scope of an integrated debugger with the command set defined in the test frame class. As in a debugger, commands can be interactively implemented on the parameters visible in the current function.

[0013] Additional features and advantages of the present invention are described in, and will be apparent from, the Detailed Description of the Preferred Embodiments and the Drawings.

[0014] FIG. 1 is a flowchart in which a individual method steps of the present invention are shown;

[0015] FIG. 2 is a flowchart of an exemplary configuration of the overall method of the present invention.

[0016] FIG. 1 shows the individual method steps of the inventive method. The set of substitute functions is defined in a first step 1a. Dependent, for example, on the type of test run, either automatic substitute functions can be created for all methods of an object-oriented program that are not yet implemented or a nesting of method calls can be resolved in that an arbitrarily selected method is implemented as a substitute function in the call hierarchy. A set of substitute functions is thus obtained that is complete insofar as at least all as yet unimplemented functions are represented by substitute functions. The automatic generation of substitute functions takes both the return parameter and the call parameter of the function to be replaced into consideration (see step 1b). In order to obtain the greatest flexibility, a general test frame class can be defined that implements an automatic status unit for each substitute function that, on the one hand, is dependent on the command set of the interpreter integrated in the test frame class and, on the other hand, is defined by the set of parameters of the substitute function or, in case the function is a method of a class, by the class belonging to the method. The test frame class has the same command set available to it for all substitute functions, this allowing access to the parameters (both handover and return parameters) that are specific to the substitute function. Further, the functionality of the substitute function can be supplemented to the effect that the test frame class, after all parameters specific to the substitute function have been defined, can be interactively operated and a command datafile can be processed independently. This corresponds to the initialization of the automatic status unit (step 1c). Interaction thereby means that, as soon as a respective substitute function has been called, the user sees a command prompt during the test run, for example at his picture screen, at which inputs can be made according to the command set predetermined in the test frame class. This procedure also can be automated in that a plurality of such commands allowed by the automatic status unit of the test frame class are combined in a command datafile that is implemented instead of the interaction. It is also possible to arrange implementation of a command datafile and switching into the mode that expects interaction with the user in an arbitrary sequence in a substitute function. Command datafiles, thus, can run exclusively in substitute functions or serve as supplementation between interactions (step 1d).

[0017] The method is distinguished in that a new compiling and linking is not required for each test run. Further, test cases can be simply automated in that the aforementioned command datafiles are employed.

[0018] An advantageous development of the inventive method is the employment of the test frame class in arbitrary modules. Since all necessary parameters of the test frame class are communicated and since the location for the interaction can be individually defined in the program code, an integrated debugging with view onto the currently valid variables is possible at the location in the program code at which the interaction is allowed. For example, operations on types that contain complex data structures can be implemented fairly simply. The interactively allowed commands can be individually implemented in the test frame class. By encapsulating the functionality for the execution of specific commands in a test frame class, it is possible to offer the functionality of the test frame class for all substitute functions by simple instancing of the test frame class in the respective substitute function.

[0019] FIG. 2 shows an exemplary configuration of the inventive method. An object-oriented modelling can be formed for example, using the programming language C++. Expediently, the classes of the system software are declared in corresponding class header files KLH. The methods of the respective classes are implemented in the appertaining program files PrgF (for example, files with the extensions .cpp or .c). When specific methods are declared within the class header files KLH but the appertaining specific implementation is lacking within the program files PrgF, the translator will output an error message that indicates that the implementation of the declared method could not be found (for example, error message “unresolved externals”). From this information about methods whose implementation is either not yet present or, on the other hand, should not be used, a test frame generator TRG generates corresponding substitute functions EF via substitute function generator EFG. To that end, the test frame generator TRG seeks the matching declaration and defines the return and call parameters therefrom. The substitute function EF also receives the same call and return parameters. In order to allow individual test runs within the substitute function EF, a test frame class is instanced in this substitute function. The test frame class has its own methods available to it that allow handover and return parameters of the substitute function EF to be communicated to the instanced test frame class. Further, a mode can be declared within the substitute function EF that, when this substitute function EF is called, allows either interaction at a command prompt or the execution of a command script. When, for example, the interaction mode is selected, the user can input various commands at a command prompt that are declared within the test frame class. This corresponds to a type of interpreter that represents an automatic status unit with the parameters of the substituted function that is defined by the test frame class and has a specific command set available to it.

[0020] It is advantageous to simulate functionality inherent in the substituted function in the substitute function EF according to the individual requirements. The encapsulation of the interpreter in its own test frame class, for example in the language C++, has the advantage that the individually defined command set of the automatic status unit declared in the test frame class is available for all instances of this test frame class in every substitute function EF. The only required activity in order to meaningfully use the automatic status unit in the test frame class is the definition of the substitute function-dependent parameters for the automatic status unit. This is automatically implemented by the substitute function generator EFG. A tool that is universal and easy to use for various test instances is obtained that can be used either manually (in the interactive mode) or automatically (with command datafiles) or both.

[0021] Although the present invention has been described with reference to specific embodiments, those of skill in the art will recognize that changes may be made thereto without departing from the spirit and scope of the invention as set forth in the hereafter appended claims.