The life of a program is a series of invocations[3]. During each invocation, the program interacts with the rest of the world, receiving inputs and, as a result, producing outputs. The specification of a program can be used to unambiguously decide whether the program's output is correct, given the input that the program received.
A program may behave non-deterministically, i.e. its results may differ between executions with identical inputs. A program is said to be correct on an input i, iff the output produced on that input is compliant with the specification of that program. The program is categorized as being faulty otherwise. The set of inputs that cause failures forms the failure Domain DF which is a subset of the input domain D[24].
: Method Inputs and Outputs
Testability is the prediction of a method's ability to reveal faults in its implementation given a particular input distribution[3]. Testability is dependent on the structure/specification and the input profile of the method. At a very early stage of the developmental cycle, the possible set of inputs and outputs to the method, together with the input profile can be used to determine the testability of a method.
A method specification that maps many inputs to a single output indicates some information loss during execution. This indicates that more information flowed into the method than flowed out. A one-to-one specification indicates that no information loss has occured. Unlike procedural systems, a method in an object-oriented program may actually have more information flow out than flowed in because it may access an attribute and return it or some subset of it. Methods that implement many-to-one specifications may produce information that is stored in its internal states and that may affect the results of program execution much later in the computation. It is our hypothesis that this uncertainty affects the amount of testing that must be performed in order to achieve a specified level of test coverage.
