# An Experimental Evaluation of Path-Based Product Line Integration Testing and Test Coverage Metrics
## 3 Path-Based SPL Integration Testing and Test Coverage Metrics
### Test Coverage Metrics for xx-MM-Paths  
Existing methods overlook platform testing and reuse problems when dealing with test coverage problems in SPLT. The proposed method, utilizing xx-MEP, effectively distinguishes between test coverage in platform testing and individual product testing of a product line, thereby offering a more comprehensive solution to avoid redundant testing. Possible SPL test coverage metrics based on the proposed method are as follows:  
* \(C_{\text{cc}}\): This coverage has the advantage of being able to pre-verify commonality through a single product of a product line because it designs and executes test cases that involve commonalities only.
* \(C_{\text{cc}}\): This coverage metric includes vc-MM-paths that consist of cc-MEPs and vc-MEPs exclusively in the test run. Because only the source node of the given vc-MM-path has variability, in order to achieve this coverage during the platform testing, for each variable source node, drivers for receiving controls from another unit and initiating/resuming a program are required.
* \(C_{\text{cp}}\): This coverage metric encompasses cv-MM-paths, which are composed exclusively of cc-MEPs and cv-MEPs. Because only the sink node of the cv-MM-path is variable, achieving this coverage during platform testing necessitates the development of drivers for sending controls to another unit and stubs for returning controls for each  
Figure 4: Hypothetical MM-path graph for an SPL. (a) MM-path across three units. (b) MM-path expressed with MEPs.  
variable sink node. Drivers and stubs should be developed to accommodate all possible values that a variation point can send or receive as controls (or messages).
* \(C_{vc+cv}\): This coverage metric encompasses MM-paths composed exclusively of cc-MEPs, vc-MEPs, and cv-MEPs. To achieve this coverage during platform testing, it is necessary to develop auxiliary test codes for variable source nodes and drivers and stubs for variable sink nodes.
* \(C_{vv}\): vv-MM-paths are tested. Because the vv-MM-path can encompass various MEPs and multiple variants, achieving this coverage in platform testing requires the development of a significant number of stubs, drivers, and auxiliary test codes to account for the variability. Furthermore, the number of v and v combinations for each vv-MEP can become uncontrollable.  
In SPLT, there may not exist an executable software product during platform development. Therefore, the cc-MM-path can perform cc-MM-path testing after deriving a representative product. Numerous studies have proposed methods for deriving such representative sample products [25]. Furthermore, vc-MM-path and cv-MM-path contain variability at the beginning and end, indicating that they can be tested during platform testing. Test coverage during product testing can be achieved by testing the vv-MM-path and application-specific parts that are not covered by platform testing.  
The SPLT has the following problem: numerous stub and driver implementations may be required due to absent variants during testing, and, in the worst case, running the test is not possible until the system is fully integrated. xx-MM-path-based integration testing not only distinguishes between common paths and variable paths but also enables variable paths to distinguish paths such as cv- or vc-MM-paths that can be tested before product testing. It is also possible to measure integration testing coverage both during platform testing and product testing, which was previously unavailable.