1
Testing object-oriented framework hook methods
Jehad Al Dallal Department of Information Sciences, Kuwait University, P.O. Box 5969, Safat 13060, Kuwait. Email:
[email protected]
ABSTRACT An application framework provides a reusable design and implementation for a family of software systems. The framework itself is not complete and users of the framework are expected to complete or extend the framework to build their particular instantiations. Places where users can add their own classes are called hooks. Hook descriptions specify how to build the methods that use the framework. These methods are called hook methods. When testing the framework, it is important to verify that the hook methods are specified correctly in the hook description. Otherwise, the generated implementations of the hook methods will not function properly. This paper introduces a technique to build a test suite for the hook methods. In addition, the paper introduces a tool that automates the testing process. The tool is applied to test several hook methods of a Client-Server Framework.
Keywords: hooks; method testing; object-oriented framework; object-oriented testing.
2 INTRODUCTION Software testing, an important and critical verification activity that is considered a time-consuming and labor-intensive task, aims at finding software errors to increase the level of confidence in the developed software. Central to the testing activities is the design of a test suite. The basic element of a test suite is a test case that describes the input test data, the test preconditions, and the expected output. For a complete test, the generated test cases must cover all invalid and unexpected input conditions and possibilities, as well as all valid and expected input conditions and possibilities. However, ensuring the complete coverage of a system under testing can be an exhaustive task due to the infiniteness of the possible input test data. To test an object-oriented application, four main testing levels have to be exercised: method testing, class testing, cluster testing, and system testing (Chen et al. 2001). At the method testing level, method responsibilities are considered. At the class testing level, the intraclass interactions and superclass/subclass interactions are examined. At the cluster testing level, the collaborations and interactions between the system classes are exercised. Finally, at the system testing level, the complete integrated system is exercised, usually based on acceptance testing requirements. This paper focuses on the method testing level. An object-oriented framework is the reusable design and implementation of a system or subsystem (Beck & Johnson 1994). When the framework is used during the framework instantiation development stage, developers build two types of classes: (1) classes that use the framework classes, and (2) classes that do not. We refer to the classes that use the framework classes as Framework Interface Classes (FICs) because they act as interfaces between the framework classes and the second type of classes created by instantiation developers. Froehlich (2002) developed the concept of hooks
3 to show how the framework is used. Hooks define how to use the framework; therefore, they define the FICs and specify the pre- and post-conditions of the FIC methods. These methods are called hook methods because they are defined by hooks. Froehlich (2002) provided a special purpose language and grammar in which the hook description can be written. The hook description includes the implementation steps and the specifications (i.e., pre- and post-conditions) of the hook methods. An example of a hook description is provided in Section 2. Hook points are the places at which framework users can add their own FICs using the hooks. Fig. 1 shows the relationship between the framework classes, the hook points, the FICs, and the other instantiation classes.
Fig. 1: Framework instantiation classes When testing the framework, it is also important to test framework hooks. If the framework hooks contain errors, the generated hook methods will not function as expected. Testing a hook includes testing whether the generated code for the hook method (using the implementation steps provided in the hook description) fulfills the specifications of the hook method defined in the hook description. What makes testing hook methods unique is that the hook methods are not implemented during the framework development stage. The framework provides guidelines for the framework
4 users to implement the hook methods at the framework instantiation stage. The guidelines are flexible such that different framework instantiations can have different implementations for the same hook method. Hook methods are part of the framework and they have to be tested before the framework is instantiated. Therefore, this paper introduces a technique to build demo implementations for the hook methods and to test them against the specifications provided in the hook descriptions. A supporting tool is introduced and used in generating and testing demo implementations for the hook methods. The paper is organized as follows. The second section discusses the related work. The third section provides an overview of the framework hooking notation. The techniques used to build and test the hook method demo implementations are introduced in the fourth and fifth sections, respectively. The sixth section discusses the automation of the testing technique. Experiments using a developed supporting tool are reported in the seventh section. Finally, the eighth section provides conclusions and a discussion of future work. RELATED WORK Several recent research studies address object-oriented testing at different levels (e.g., Binder 1999, Sykes & McGregor 2001, Daley et al. 2002, Mouchawrab et al. 2005, Briand et al. 2006, Gallagher & Offut 2006, Gallagher et al. 2007). This paper focuses on testing at the method level. To test the methods inside classes, conventional white and black box testing techniques can be applied. In white box testing (Beizer 1990, Roper 1994, Chen & Low 1995, Binder 1999, Boujarwah et al. 2000, Saleh et al. 2001), the method control and data flow are analyzed. In black box testing, conventional black box testing techniques, such as domain testing, equivalence partitioning, and boundary value analysis can be used (Beizer 1990,
5 Binder 1999, Grindal et al. 2005). In domain testing, test data near the borders of the data region are selected. With the equivalence partitioning technique, the input domain is divided into distinct equivalence partitions and test data is selected for each partition. Several techniques have been introduced to test frameworks and their instantiations. In Binder (1999) and Al Dallal & Sorenson (2002), techniques were introduced to test the framework at the system level. Binder (1999) suggested building a demonstration application that requires minimal implementation of each framework use case. Test cases have to be developed to test the demo application using existing object-oriented testing techniques. Al Dallal & Sorenson (2002) suggested using hook descriptions to build demo applications to test the framework components at the system level. In Al Dallal & Sorenson (2005), Tsai et al. (1999), and Wang et al. (2000), several techniques were proposed to test the framework instantiations. Al Dallal & Sorenson (2005) suggested building reusable test cases during the framework development stage and using them during the framework instantiation stage to test the implemented FICs at the class level. Tsai et al. (1999) introduced a technique to test the interactions between the FICs in a developed framework instantiation and the framework classes. Wang et al. (2000) proposed providing the framework with reusable test cases that can be applied at the instantiation development stage. None of these techniques addresses the testing of hook methods. Kauppinen et al. (2004) proposed a criterion to evaluate the hook coverage of a test suite used to test hook methods. The hook method coverage is defined as the structural coverage (e.g., statement coverage) of a hook method implementation provided by the test cases that reach the method. Kauppinen et al. (2004) suggested building hook implementations and test cases for the hook methods
6 and using the hook method coverage criterion to evaluate the coverage of the test cases. However, no discussion was provided on how to build the hook implementations and the test cases. RITA (Tevanlinna 2004) is a software tool that supports framework testing and automates the calculation of the hook method coverage measure. The user of the tool has to provide implementations for the hook methods. The work on testing the software product lines and product families is relevant to the problem addressed in this paper. A software product family is a set of software products that shares common features (Bosch 2000). The natural core of a product family is a set of software assets that is reused across products (Tevanlinna et al. 2004). Variation points are points at which the products of a product family differ (i.e., each product has a different implementation, which is called a variant, for an abstract class associated with a variant point) (Cohen et al. 2006). In frameworkbased software product families, the variation points are the hook points, and implementations of the FICs are the variants. McGregor (2001) suggested testing the product line core assets before using them in building the product. Methods of classes associated with variation points can be tested using pre-built variants produced by the product line organization. McGregor (2001) and Cohen et al. (2006) suggested using combination testing strategies to build test cases to test product line variants. However, these approaches cannot be used to test hook methods (i.e., methods in FICs) at the framework development stage during which no implementations for FICs are provided.
7 FRAMEWORK HOOK DESCRIPTION Froehlich et al. (1997) and Froehlich (2002) describe the issue of documenting how the framework should be used. This is done by using the concept of hooks, which describe how to extend or customize parts of the framework to build an application. Froehlich (2002) identified four levels of support provided for adaptation within the framework: option, supported template, open, and evolutionary. At the option level, a number of pre-built components are provided within the framework, and the developer chooses one without needing extensive knowledge about the framework. At the template level, the developer supplies parameters for components and follows a well-supported pattern of behavior. At the open level, the developer adds new properties to classes, new classes to the framework, or extends the framework’s functionality. At the evolutionary level, the developer changes parts of the framework code or breaks invariants defined on the framework. The four levels of support are provided at the hook points. A hook description documents the use of the framework at the first three levels of support. The fourth level of support describes the framework misuse, and therefore, it is not documented. Froehlich (2002) provided a special purpose language and grammar in which the hook description can be written. Each hook description consists of the following parts: (1) a unique name; (2) the requirement (i.e., the problem the hook is intended to help solve); (3) the hook type; (4) the other hooks required to use this hook; (5) the components that participate in this hook; (6) the pre-conditions (i.e., the constraints on the parameters or the context that must be true before the hook can be used); (7) the changes that can be made to develop the instantiation (i.e., implementations steps for the hook methods); (8) the post-conditions (i.e., constraints on the parameters that must be true after the hook has been used); and (9) a general comments section. It is
8 not necessary to have all the above components for each hook. Multiple hook descriptions can provide specifications and implementation steps for the same method. In this case, each hook description provides implementation steps to build the hook method that satisfies the specifications provided in the same hook description. Fig. 2 shows an example of a hook description for the creation of an account in a banking framework. The Initialize Account hook creates an init hook method that should be called up when an account is constructed. In the init method, the account money currency is selected. There are three built-in classes in the framework for money: USMoney, EURMoney, and Money. Moreover, the user has to specify the bank branches in the system. Name: Initialize Account Requirement: Initialize an account (i.e., set the currency and bank branches). Type: Template Uses: None Participants: Account(framework), NewAccount(app), Amoney(app); Pre-conditions: Subclass NewAccount of Account; Changes: New operation NewAccount.init(); Choose AM from (Money, USMoney, EURMoney); Acquire BaseAmount: float domains:0.00- 9999999.99; Create Object Amoney as AM(BaseAmount) in MyAccount.init(); Create Object branches as Branches() in NewAccount.init(); Repeat as necessary { Acquire BranchName: string NewAccount.init() -> branch.addBranch(BranchName); } Post-conditions: Operation NewAccount.init(); NewAccount.AT.getBaseAmount>=0.00 &&NewAccount.AT.getBaseAmount
