# An Experimental Evaluation of Path-Based Product Line Integration Testing and Test Coverage Metrics
## 3 Path-Based SPL Integration Testing and Test Coverage Metrics  
### Path-Based SPL Integration Testing  
In single software testing, the path-based integration method offers the advantage of not needing stub and drive development, which typically demand a significant amount of test effort during integration testing. The path-based integration avoids the need for developing stubs and drivers by directly utilizing the original development code. [PERSON] [24] proposed the MM-path method, a technique based on method-message paths. An MM-path is represented as a series of module execution paths (MEPs), which are sequences of statements starting from a source node and ending at a sink node, without any intermediate sink nodes. In this context, the source node refers to a state fragment or executed lines of a program. Figure 1 illustrates an example of an MM-path graph, describing the message interaction between the two methods belonging to different modules. In this example, there are several possible MEPs, including MEP-A1<a1, a2, a3, a4>, MEP-A2<a4, a5, a7, a8>, MEP-A3<a4, a6, a7, a8>, MEP-B1<b1, b2, b3>, and MEP-B2<b4, b5>. One particular MM-path comprises MEP-A1, MEP-B1, and MEP-A3. Each MM-path serves as a test case covering the integration path, as shown in Figure 2. In Figure 2, the dotted arrow represents the return path. The MM-path represents a path that focuses on interaction between different units. MM-path-based integration testing in single software testing can be employed for SPL  
Figure 1: An MM-path between the two methods belonging to different modules. Figure 2: An MM-path graph using MEPs. integration testing because interactions among units in SPL are fundamentally performed through method calls between different units. The primary challenge in using MM-path-based integration testing for SPLT is to effectively handle variabilities that distinguish different products of a product line. The variabilities of a unit are tested during unit testing, much like unit testing of single software testing does. Consequently, integration testing concentrates solely on interactions between units, making it essential to consider the variability involved in these interactions. Regarding commonalities, once they have been tested, redundant testing should be avoided. In this context, types of MM-paths in SPLT depend on the commonality and variability of modules. Thus, this paper divides the statement fragment used by [3] as a basic concept for extracting the nodes constituting the path into the following two types [8]:  
* Common statement fragment: A sequence of statements, methods, or modules commonly shared by all products of a product line. A statement can consist of a single node. * Variable statement fragment: A sequence of statements, methods, or modules that are either shared by two or more products of a product line or used by a single product of a product line. A statement can consist of a single node. Based on the two types of MM-paths, the starting and ending source and sink nodes of each MEP can be categorized as common and variable types, respectively:  
* Common source node: a common node where program execution starts or resumes. * Variable source node: a variable node where program execution starts or resumes. * Common sink node: a common statement fragment at which program execution terminates or transfers control to other units. * Variable sink node: a variable statement fragment at which program execution terminates or transfers control to other units. In SPLT, the MEP is identical to single software testing in that it represents a series of paths from the source node to the sink node within the same unit. However, in contrast to earlier work [3], I leverage the MEP as a coverage metric consisting of common and/or variable nodes as its elementary units, with the goal of reducing redundant testing in SPLT. The MEP can take various forms, considering the combination of common or variable nodes. This study defines the following two paths: an MEP and an MM-path formed based on the MEPs.