Testing software components for integration: a survey of issues and techniques

Abstract

Component‐based development has emerged as a system engineering approach that promises rapid software development with fewer resources. Yet, improved reuse and reduced cost benefits from software components can only be achieved in practice if the components provide reliable services, thereby rendering component analysis and testing a key activity. This paper discusses various issues that can arise in component testing by the component user at the stage of its integration within the target system. The crucial problem is the lack of information for analysis and testing of externally developed components. Several testing techniques for component integration have recently been proposed. These techniques are surveyed here and classified according to a proposed set of relevant attributes. The paper thus provides a comprehensive overview which can be useful as introductory reading for newcomers in this research field, as well as to stimulate further investigation. Copyright © 2006 John Wiley & Sons, Ltd.

An Empirical Study of Adoption of Software Testing in Open Source Projects

“…Greiler et al conduct a qualitative study of test practices followed by a community of people working on plug-in based applications [14]. Rehman et al discuss several software component testing issues and classify set of testing techniques used when a component is integrated with its target system [34]. Memon et al present their analysis to improve the current testing techniques and strategies to create new collaborative development and testing processes where developers can share tools and information repositories [23].…”

Testing-based assessment process for upgrading component systems

“…every service from each interface is invoked at least once. In [20,35] this is called all-interface. • all-events [36].…”

“…The goal of this TS is to check that a candidate component K coincides on behaviour with a given original component C. Therefore, each test case in TS will consist of a set of calls to C's services, from where the testing results are saved on a repository for determining acceptance or refusal when the TS is applied against component K. Following are listed some relevant component coverage notions [20], explaining the strategy for their implementation on the approach.…”

“…Not only input and output should be equivalent on both components, but mainly the right generation of a particular output from a specific input, which is referred to as functional mapping. The Observability testing metric [14,20] is particularly focused on analyzing the functional mapping performed by a component, which helps to understand its behaviour. This may be used to expose a potential compatibility between components -as discussed in [1,6].…”

“…The compatibility analysis is mainly based on the Observability testing metric [14,20]. The central idea is to observe the operational behaviour of a component (i.e.…”