Software Engineering-Interclass Test case Design

Test case design becomes more complicated as integration of the OO system begins. It is at this stage that testing of collaborations betwee...

Test case design becomes more complicated as integration of the OO system begins. It is at this stage that testing of collaborations between classes must begin. To illustrate “interclass test case generation” , we expand the banking example to include the classes and collaborations noted in Figure below The direction of the arrows in the figure indicates the direction of messages and the labeling indicates the operations that are invoked as a consequence of the collaborations implied by the messages.

Like the testing of individual classes, class collaboration testing can be accomplished by applying random and partitioning methods, as well as scenario-based testing and behavioral testing.

Multiple Class Testing

Kirani and Tsai suggest the following sequence of steps to generate multiple class random test cases:

1. For each client class, use the list of class operations to generate a series of random test sequences. The operations will send messages to other server classes.

2. For each message that is generated, determine the collaborator class and the corresponding operation in the server object.

3. For each operation in the server object (that has been invoked by messages sent from the client object), determine the messages that it transmits.

4. For each of the messages, determine the next level of operations that are invoked and incorporate these into the test sequence.

To illustrate , consider a sequence of operations for the bank class relative to an ATM class :

verifyAcct•verifyPIN•[[verifyPolicy•withdrawReq]|depositReq|acctInfoREQ]n

A random test case for the bank class might be

test case r3 = verifyAcct•verifyPIN•depositReq

In order to consider the collaborators involved in this test, the messages associated with each of the operations noted in test case r3 is considered. Bank must collaborate with ValidationInfo to execute the verifyAcct and verifyPIN. Bank must collaborate with account to execute depositReq. Hence, a new test case that exercises these collaborations is The approach for multiple class partition testing is similar to the approach used for partition testing of individual classes.  However, the test sequence is expanded to include those operations that are invoked via messages to collaborating classes. An alternative approach partitions tests based on the interfaces to a particular class. Referring to figure, the bank class receives messages from the ATM and cashier classes. The methods within bank can therefore be tested by partitioning them into those that serve ATM and those that serve cashier. State-based partitioning  can be used to refine the partitions further.

Tests Derived from Behavior Models

We already discussed the use of the state transition diagram as a model that represents the dynamic behavior of a class. The STD for a class can be used to help derive a sequence of tests that will exercise the dynamic behavior of the class (and those classes that collaborate with it). Figure below illustrates an STD for the account class  Referring to the figure, initial transitions move through the empty acct and setup acct states. The majority of all behavior for instances of the class occurs while in the working acct state. A final withdrawal and close cause the account class to make transitions to the nonworking acct and dead acct states, respectively.

test case r4 = verifyAcctBank[validAcctValidationInfo]•verifyPINBank•
                    [validPinValidationInfo]•depositReq• [depositaccount] 

The tests to be designed should achieve all state coverage . That is, the operation sequences should cause the account class to make transition through all allowable states:

test case s1: open•setupAccnt•deposit (initial)•withdraw (final)•close

It should be noted that this sequence is identical to the minimum test sequence . Adding additional test sequences to the minimum sequence,

test case s2: open•setupAccnt•deposit(initial)•deposit•balance•credit•withdraw (final)•close

test case s3: open•setupAccnt•deposit(initial)•deposit•withdraw•accntInfo•withdraw (final)•close

Still more test cases could be derived to ensure that all behaviors for the class have been adequately exercised. In situations in which the class behavior results in a collaboration with one or more classes, multiple STDs are used to track the behavioral flow of the system.

The state model can be traversed in a “breadth-first”  manner. In this context, breadth first implies that a test case exercise a single transition and that when a new transition is to be tested only previously tested transitions are used.

Consider the credit card object discussed earlier. The initial state of credit card is undefined (i.e., no credit card number has been provided). Upon reading the credit card during a sale, the object takes on a defined state; that is, the  attributes card number and expiration date, along with bank specific identifiers are defined. The credit card is submitted when it is sent for authorization and it is approved when authorization is received. The transition of credit card from one state to another can be tested by deriving test cases that cause the transition to occur. A breadth-first approach to this type of testing would not exercise submitted before it exercised undefined and defined. If it did, it would make use of transitions that had not been previously tested and would therefore violate the breadth-first criterion.