Seventh IEEE/ACIS International Conference on Computer and Information Science
Enhancing Data Flow Testing of Classes through Design by Contract Yogesh Singh School of IT, GGSIP University,
[email protected]
Anju Saha School of IT, GGSIP University
[email protected]
Abstract Hence through contract specification we produce quality test cases. 2) Since our specification is executable, it helps in finding whether a test case (message sequence) should be generated or not. This technique has been validated through a number of C++ classes. We have compared the testing of a DbC class with a conventional class. A DbC class is different from a conventional class because in a DbC class methods are embedded with pre and postconditions and has a class invariant. Through this technique we find that the numbers of du pairs are reduced in a DbC class because some of the conditions in conventional class become the part of the precondition in a DbC class. Execution of a test case (sequence of messages) in a DbC class and a conventional class is as shown in figure 1.
Design by Contract (DbC) is a methodology to construct quality software. DbC associates the contract specification (pre and postconditions of methods of class and class invariant) with the design of a class. In this paper, we combine data flow testing and Design by Contract to develop a testing technique called “Data flow testing using Contract”. In this technique a class flow graph is generated from the contract specification of the class and then conventional data flow testing is applied to find the test cases. The advantage of using contract specification is that: it is executable and hence a method in a test case is only executed if its precondition and class invariant are satisfied. If they are not satisfied then it leads to an infeasible sequence. Also, if after executing a method its postcondition is not satisfied then it leads to implementation error in the method. We also compare the testing of a DbC class with a conventional class and find that the number of du pairs is reduced in a DbC class because some of the conditions in conventional class become the part of the precondition in a DbC class.
M1 M2 M3 M4 M5
M6
Implementation error in M3
1. Introduction M1 M2 M3 M4 M5
Design by Contract (DbC) is an approach for constructing object oriented software to improve the quality of the software [1]. In this paper, we combine data flow testing and design by contract to develop a testing technique called “Data flow testing using Contract”. In this technique a class flow graph is generated from the contract specification of the class (pre, postconditions of methods and class invariant) and then conventional data flow testing is applied to find the test cases. This technique generates the test cases (message sequences) on the basis that: a method M2 can be invoked after method M1 only if postcondition of M1, precondition of M2 and class invariant are true. Our approach is different from other specification based approaches [2, 8, 9, 15, 18] in two ways: 1) our approach uses contract specification, which is executable hence a method in a test case is executed only if its precondition and class invariant are satisfied. If it is not satisfied then it leads to an infeasible sequence. Also if after executing a method its postcondition is not satisfied then it leads to implementation error in the method.
978-0-7695-3131-1/08 $25.00 © 2008 IEEE DOI 10.1109/ICIS.2008.70
M6
Figure 1: DbC Vs Conventional test case execution Let us take a test case containing messages M1, M2, M3, M4, M5, M6. Now, suppose there is an error in the implementation of method M3. Then that error is known after the execution of M3 in a DbC class because the postcondition of M3 comes out to be false. Since postcondition of M3 is false hence M4 cannot be executed and it tells that there is an error in the M3 method. But for conventional class (which is not having any contracts) all the methods from M1 to M6 are executed and error is known only after the execution of M6. Also we don’t know where the error is. This shows that an error in a DbC class is known earlier than in a conventional class. The organization of the rest of the paper is as follows: section 2 describes design by contract, section 3 describes the proposed class testing technique, section 4 describes the comparison with conventional programming,
567
section 5 describes the case study and section 6 gives the related work and conclusions.
4. Breaking of postcondition of a method tells about the implementation error in the currently executed method. Software contracts have been used in various ways to improve the quality of the software like: in the design of testability of a class and object oriented code [3, 19], in testing the scenario
2. Design by Contract (DbC) Design by contract was originally developed by Meyer [1] to improve the reliability of software and hence the quality of the software. Since reliability is a major component of software quality. It is a methodology that associates contract specification with the design of the class. A contract specification is made up of following three components. 1. Precondition of method: A precondition defines the conditions which should be true before the execution of the method of the class. Each method of a class has a precondition. 2. Postcondition of method: A postcondition defines the conditions which should be true after the execution of the method of the class. Each method of a class has a postcondition. 3. Class Invariant: Class invariant states the conditions which should be true for all the objects of a class. The invariant must be satisfied after the execution of a method if it was satisfied before the execution of the method. Invariant is a constraint that checks the consistency of the states of an object throughout its life cycle [1]. Invariant should be true after the creation of every object of a class. An example of a queue class developed using DbC is shown in figure 2. DbC class contains preconditions and postconditions of methods and a class invariant. Mathematically DbC can be expressed as: (I and Pre) M (Post and I) Where I is the class invariant, Pre and Post are the precondition and postcondition of the method M of the class respectively. A method of a class is executed if its precondition and class invariant are satisfied. After the method execution the postcondtion of the method and class invariant should be satisfied. Based on above formula we can test the sequences of methods as follows: (I and Pre1) M1 (Post1 and I and Pre2) M2 (Post2 and I and Pre3)……………. (I and PreN) MN (PostN and I) In the above sequence any method Mi can only be invoked if its precondition, class invariant and postcondition of method Mi-1 are satisfied. Since the number of test sequences can be infinite. Hence to choose a set of quality test cases data flow testing criterion is chosen. Design by Contract is a well established way of producing quality software and from above we can deduce that this methodology produces quality test cases because: 1. The test sequences (message sequences) are executed only if the contract (precondition, postcondition and class invariant) is satisfied. 2. Due to assertions (contracts) some of the p-uses are not generated which reduces the number of du pairs. 3. Breaking of the precondition of a method directly tells about the infeasibility of the test sequence.
class queue { int q_Array[SIZE]; int front; int rear; public: queue(); void add(int i); int remove(); }; queue::queue(){ Pre(true); front=0; rear=0; Post(front ==0 && rear==0) } void queue::add(int i){ Pre (rear= 0 && rear >= 0 && front
