On built-in test reuse in object-oriented framework design

Abstract

Object-oriented frameworks have extended reusability of software from code modules to architectural and domain information. This paper further extends software reusability from code and architecture to built-in tests (BITs) in object-oriented framework development. Methods for embedding BITs at object and object-oriented framework levels are addressed. Behaviours of objects and object-oriented frameworks with BITs in the normal and test modes are analyzed. Systematic reuse methods of BITs in object-oriented framework development are provided. The most interesting development in the paper is that the BITs in object-oriented frameworks can be inherited and reused as that of code. Therefore testability and maintainability of the test-built-in object-oriented frameworks can be improved by the BIT approach. The BIT method can be used in analysis, design and coding of object-oriented frameworks.

Estimating the coverage of the framework application reusable cluster-based test cases

“…Some of these testing techniques are proposed specifically to test object-oriented frameworks, including [1,12,[24][25][26]. Others are proposed specifically to test object-oriented framework instantiations, including [16][17][18]24,27].…”

“…These test scenarios are used to test sequence constraints on the interaction between framework objects and custom objects. Wang et al [16], propose providing the framework with reusable class-based test cases that can be applied during the application engineering stage. Al Dallal [17] and Al Dallal and Sorenson [18,19] propose a technique to test the FICs at class-level using reusable test cases built during the framework domain engineering stage.…”

“…[11]), testing the use of class libraries (e.g. [12]), testing software product-lines [13][14][15], and testing object-oriented framework applications [16][17][18][19]. Building reusable test cases for the framework applications at the framework development stage increases the framework development time and cost.…”

Jata: A Language for Distributed Component Testing

“…Usually, a distributed component may have multiple concurrent connections with its clients. Formally said, distributed component has the unique characteristics like: (1) can have two ways to be invoked, RPC-based and message-based; (2) user program can host in various environments that keep transparent to the component; (3) can have multiple concurrent connections at the same time, and the component can maintain the interaction state for every client; (4) the call parameters needs to be marshaled by client to send via a network, and the component needs to unmarshal the parameters to process the invocation [2]; (5) the interface of in-house developed component usually has to be changed to adapt to the application when the requirement or design changes. Based on the uniqueness of the distributed component, we can find Junit is not qualified for the testing because each test client in Junit has its own private instance of the distributed component under test (CUT).…”

“…It can be done by support tools. For example, TTWorkbench, the TTCN-3 development and execution platform delivered by Testing Technologies, supports distribution testing by the special tool, ttmex 3 .…”