We noted that software testing begins “in the small” and slowly progresses toward testing “in the large.” Testing in the small focuses on a...
We noted that software testing begins “in the small” and slowly progresses toward testing “in the large.” Testing in the small focuses on a single class and the methods that are encapsulated by the class. Random testing and partitioning are methods that can be used to exercise a class during OO testing .
Random Testing for OO Classes
To provide brief illustrations of these methods, consider a banking application in which an account class has the following operations: open, setup, deposit, withdraw, balance, summarize, creditLimit, and close . Each of these operations may be applied for account, but certain constraints (e.g., the account must be opened before other operations can be applied and closed after all operations are completed) are implied by the nature of the problem. Even with these constraints, there are many permutations of the operations. The minimum behavioral life history of an instance of account includes the following operations:
open•setup•deposit•withdraw•close
This represents the minimum test sequence for account. However, a wide variety of other behaviors may occur within this sequence:
open•setup•deposit•[deposit|withdraw|balance|summarize|creditLimit]n•withdraw•close
A variety of different operation sequences can be generated randomly. For example:
Test case r1: open•setup•deposit•deposit•balance•summarize•withdraw•close
Test case r2: open•setup•deposit•withdraw•deposit•balance•creditLimit•withdraw•close
These and other random order tests are conducted to exercise different class instance life histories.
Partition Testing at the Class Level
Partition testing reduces the number of test cases required to exercise the class in much the same manner as equivalence partitioning for conventional software. Input and output are categorized and test cases are designed to exercise each category. But how are the partitioning categories derived?
State-based partitioning categorizes class operations based on their ability to change the state of the class. Again considering the account class, state operations include deposit and withdraw, whereas nonstate operations include balance, summarize, and creditLimit. Tests are designed in a way that exercises operations that change state and those that do not change state separately. Therefore,
Test case p1: open•setup•deposit•deposit•withdraw•withdraw•close
Test case p2: open•setup•deposit•summarize•creditLimit•withdraw•close
Test case p1 changes state, while test case p2 exercises operations that do not change state (other than those in the minimum test sequence).
Attribute-based partitioning categorizes class operations based on the attributes that they use. For the account class, the attributes balance and creditLimit can be used to define partitions. Operations are divided into three partitions: (1) operations that use creditLimit, (2) operations that modify creditLimit, and (3) operations that do not use or modify creditLimit. Test sequences are then designed for each partition.
Category-based partitioning categorizes class operations based on the generic function that each performs. For example, operations in the account class can be categorized in initialization operations (open, setup), computational operations (deposit, withdraw). queries (balance, summarize, creditLimit) and termination operations (close).
