Posts Tagged pop

Interacting Functions, Non-temporal Approach

In contrast to a hierarchy of functions now we consider functions that do not necessarily have a calling relation. However, we assume that the functions work together though, e.g. operate on common data, with the objective to achieve a common goal.

The well-known abstract data type “stack” with its push() and pop() operations is a very simple example for that. The isolated testing of push() and pop() is unit testing, but this is not sufficient here – integration testing is needed. Integration testing would consist of a sequence of push() and pop() calls. The input for such a test case is formed by the parameter values of push() and the initial contents of the stack. The results are the return values of pop() and the final state of the stack. In the case where calls to push() and pop could result in additional calls, e.g. to error handling functions for stack overflow/underflow, such calls also belong to the expected result of an integration test case.

push and pop of the abstract data type stack

For push() and pop() of the abstract data type "stack", unit testing is not sufficient.

The term „module“ may be appropriate for such a collection of cooperating functions, but in Tessy the term „component“ is used, still because of the inappropriate connotation to C source modules.

Internal structure of a component and its interface

The internal structure of a component and its interface to the outside world

At least one of the functions combined in a component must be callable from the outside of the component to stimulate the functionality of the component.

Normally several functions are callable from external. We call these functions “component functions”. A test for a component is no longer a single function call (as in the two sections above) but a sequence of calls to the component functions. The calls to the component functions stimulate the component. Like testing of a single function, a test case for a component also comprises of input and output data (variables of the component and parameters of the called component functions).

A test case for a component is called “scenario” in Tessy.

A component may have internal functions that can not be called from the outside of the component, but only from functions inside the component.

What internal functions do (if some exist at all) is not relevant for component testing, because component testing takes the component as a black box. However, relevant for the result of a component test is the sequence of the calls from within the component to functions in other components. This is with respect to the number of the calls, the order of the calls, and the parameters passed by the calls to other components.

Obviously, the functionality of the functions in a component and the interfaces between them are tested by component testing, at least for the most part. Hence, component testing can be considered well as integration testing for the functions in the component.

, , , , , , , ,

No Comments