Object state testing

Object state testing is a formal white-box software test design method testing object state behavior. State testing is complementary to local error detection of functional and structural testing. Interaction of class member functions are tested through object state transitions. An object behavior is state based arranged due to method invocation sequence, which behavior is established due to parameter values and state, providing successor and return value. The ranges of values of a subset of member data of the object defines a state of an object. State transitions are deterministic finite due to the conditional execution of member functions. Object state tests can be determined from the source code (white-box) or from the specifications (black-box).

Requirements

1. Initial state
2. Parameter arguments
3. Expected return value
4. Expected object successor state

Defects

To ensure robustness, all void and valid method sequence invocation combinations need to be tested using state test cases. Testing the object state brings out the following defects.

1. Missing state transition
2. Invalid transitions
3. Wrong return value
4. Invalid successor state

Object States

The behavior of a class object is definable and characterized by inhabited data member values. The run time execution path is determined by evaluating member and parameter values in decisions (conditions), affecting the class object behavior. Object states are segmented into independent domain member data interval combinations leading towards different execution paths.

State characterization

1. Examine all path conditions of member functions for conditional literals
2. For each conditional literal found, form domain intervals such that the conditional literal is evaluated to either True or False for all values in the interval.

Coverage

The amount of states and paths circumscribes test state coverage. Due to possible infinite cyclic path sequences, the path length needs limitation. The amount of methods $n$ is a minimum criterion of path length for permutations of method sequences $n!$. Instead of limiting method permutation sequences, an acyclic spanning tree addresses systematically path length including negative and positive path combinations through a state space.

Example

A soda machine requires two 50c coins for a soda. It provides five methods and three class member variables. The variable tmp holds temporary coins until a customer withdraws a soda

#!/anaconda/bin/python
class SodaMachine:

    total = 0
    tmp = 0
    withDraw = False

    def __init__(self):
        self.reset()

    def add50c(self):
        self.tmp = self.tmp + 1
        if self.tmp > 1:
            self.withDraw = True

    def return50cs(self):
        self.tmp = 0

    def canWithDraw(self):
        return self.withDraw

    def draw(self):
        if self.withDraw:
            self.total = self.total + self.tmp
            self.tmp = 0
            self.withDraw = False

    def reset(self):
        self.total = 0
        self.tmp = 0
        self.withDraw = False

    if __name__ == '__main__':
        sodaM = SodaMachine()
        sodaM.add50c()
        sodaM.add50c()
        sodaM.draw()

State Definition

The class contains the conditions:

1. add50c(): if self.tmp > 1
   

2. draw(): if self.withDraw
   

The two conditions are segmenting the class member variable values into four states $S_1,S_2,S_3,S_4$:

	Member Interval
State	tmp	withDraw	validity
$S_0$	$x<1$	False	✓
$S_1$	$x>1$	True	✓
$S_2$	$x<1$	True	✗
$S_3$	$x>1$	False	✗

State transition spanning tree

See also

• Multiple condition coverage
• Control flow graph
• Decision to decision path
• Elementary comparison testing

References

This article "Object state testing" is from Wikipedia. The list of its authors can be seen in its historical and/or the page Edithistory:Object state testing. Articles copied from Draft Namespace on Wikipedia could be seen on the Draft Namespace of Wikipedia and not main one.

---