Affected Component Coupling in Regression Testing

• Affected Component Coupling (ACC) is a metric that measures interdependence among change-affected parts of a program to estimate fault-proneness.
• ACC is computed over an Affected Slice Graph (ASG), capturing forward and backward dependencies to inform regression test prioritization.
• Empirical findings show that ACC-guided prioritization improves fault detection rates and APFD by targeting highly coupled, fault-prone nodes.

Searching arXiv for the specified ACC-related papers to ground the article in current preprints. First, I'll retrieve the core 2025 paper defining Affected Component Coupling in regression test prioritization. Now I'll check closely related coupling-analysis papers for context and terminology disambiguation. Affected Component Coupling (ACC) is a static metric for quantifying the degree of interdependence among change-affected parts of an object-oriented program, with the explicit purpose of estimating fault-proneness and improving regression test case prioritization. In the formulation introduced for slice-based change impact analysis, ACC is computed over an Affected Slice Graph (ASG), a dependency graph restricted to affected program parts, and higher ACC values indicate components that both depend on many other affected nodes and are depended upon by many other affected nodes, making them more likely to propagate faults or participate in change ripple effects (Panda et al., 26 Aug 2025). In broader coupling-oriented software engineering literature, ACC is also discussed more generally as the extent to which modifications to a component affect other components via dependencies, although the mathematically explicit definition is given in the regression-testing setting (Hasan et al., 2010).

1. Definition and conceptual scope

Affected Component Coupling is defined as a metric devised to measure the degree of interdependence between affected parts of an object-oriented program after a change. The metric is designed to reflect the fault-proneness of program components affected by a change; components with higher ACC are considered more prone to faults if they are changed (Panda et al., 26 Aug 2025).

The central intuition is structural. A program node that both depends on many other nodes and is depended upon by many other nodes is, when changed, more likely to propagate faults or suffer from a change ripple effect. ACC therefore operationalizes a coupling-based view of change impact: it does not simply identify whether a component is affected, but estimates how strongly that component is embedded in the affected dependency region (Panda et al., 26 Aug 2025).

In this sense, ACC is narrower than generic coupling metrics and more specific than whole-program centrality measures. It is restricted to affected program parts rather than the entire codebase, and it is explicitly tied to post-change analysis. This suggests that ACC should be understood as an impact-focused coupling metric rather than as a general-purpose architectural quality indicator.

2. Affected Slice Graph and the impacted region

The computation of ACC depends on the construction of the Affected Slice Graph. The ASG is constructed to explicitly model only the program parts affected by a change. The construction process begins from the change location as the slicing criterion. A forward slice traverses the program's dependence graph from the point of change and collects all nodes that are potentially affected. For each node reached in the forward traversal, a backward slice then traverses backward to find nodes that influence that node. The union of these sets gives the ASG, where nodes are affected components and edges represent dependencies including control, data, inheritance, call, and membership (Panda et al., 26 Aug 2025).

The ASG therefore encodes both the impact area of the change and the dependencies among affected nodes. This is important because ACC is not measured over arbitrary program structure, but over the subgraph induced by change relevance. The metric is consequently sensitive to the local dependency topology of the affected region rather than to the full software graph.

A broader coupling literature provides useful context for this representation strategy. In Java systems, interaction graphs have been used to represent software structure as a graph where nodes are classes and edges represent Operation-Operation or Class-Class interactions. Those interactions include return types, argument passing in member functions, object declaration, and inheritance (Hasan et al., 2010). Although that work does not define ACC with the same formula, it supports the underlying premise that inter-class and inter-module relationships can be represented graphically and measured through graph structure.

3. Mathematical formulation

For a node $n$ in the ASG, ACC is calculated as a normalized sum of its incoming and outgoing dependencies, called inflow and outflow respectively. Inflow is the set of nodes on which $n$ directly depends. Outflow is the set of nodes that, directly or indirectly, depend on $n$. The dependence set for node $n$ is

$\psi(n) = \text{Inflow}(n) \cup \text{Outflow}(n)$

and the ACC formula is

$$ACC(n) = \frac{|\text{Inflow}(n)| + |\text{Outflow}(n)|}{|N_a| - 1}$$

where $|N_a|$ is the number of nodes in the ASG, and the subtraction of 1 in the denominator adjusts for the node itself (Panda et al., 26 Aug 2025).

Higher ACC means that a node is more tightly coupled to the rest of the affected system, so an error there is more likely to propagate. The metric therefore combines local dependence and affected-region reachability into a single normalized quantity. A plausible implication is that ACC functions as a change-scoped analogue of degree-based risk estimation, but with outflow defined in terms of direct or indirect dependence rather than immediate adjacency.

The same work also defines aggregate ACC values for compound nodes such as methods, classes, and packages. For a method node $M$ with $j$ member elements having ACC values $ACC(n_1), ACC(n_2), \ldots$, the method-level value is

$n$0

For a class node $n$1 with $n$2 members, the class-level value is

$n$3

A similar formula is applied to package nodes using class and subpackage components (Panda et al., 26 Aug 2025).

These aggregation rules preserve the coupling interpretation across granularity levels. They also indicate that ACC is intended to support analysis at the statement, method, class, and package levels rather than being confined to a single representation scale.

4. Role in change impact analysis

In change impact analysis, ACC is used to identify which program elements are most likely to be fault-prone after a change by computing their coupling within the ASG. Nodes with higher ACC are considered more likely to be error-prone if impacted by a change because of their centrality and connectivity within the impacted region (Panda et al., 26 Aug 2025).

This use of coupling for impact assessment is consistent with a long-standing design principle in object-oriented software engineering: collaboration should be kept to an acceptable minimum, because highly coupled systems are difficult to implement, to test, and to maintain over time (Hasan et al., 2010). That earlier literature distinguishes necessary coupling from unnecessary coupling and links low coupling to maintainability and reusability. ACC refines this perspective by moving from whole-system design quality to change-localized fault risk.

A related systems modeling framework generalizes the same idea at component-interface level. There, a system is represented as a directed graph of couplings, and ACC corresponds to the estimation and mapping of components impacted directly or indirectly by a change induced by external requirements; specifically, it is the set of components reachable via coupling paths starting from the changed interface or requirement (Chan, 30 Jun 2026). That framework treats change propagation paths by traversing outgoing edges in a directed system graph, and the set of reachable nodes is the ACC set (Chan, 30 Jun 2026). This suggests a close conceptual correspondence between ASG-based ACC in source-code analysis and reachability-based affected coupling in architecture-level models.

5. Regression test case prioritization workflow

The primary operational use of ACC in the 2025 formulation is regression test case prioritization. After constructing the ASG and computing ACC for all ASG nodes, all nodes’ ACC values are clustered using k-means with $n$4 into three fault-proneness categories: Critical ($n$5, weight $n$6), Moderate ($n$7, weight $n$8), and Weak (otherwise, weight $n$9) (Panda et al., 26 Aug 2025).

For each test case, the weight is the sum of weights of the nodes it covers as determined through code coverage. If multiple test cases have the same total weight, further tiebreaks use the sum of critical, then moderate, then weak node weights. The test suite is then prioritized by decreasing total test case weight, emphasizing tests that execute fault-prone affected code first (Panda et al., 26 Aug 2025).

The workflow can be summarized as follows.

Step	Operation	Result
1	Construct ASG for the modified version	Affected dependency subgraph
2	Compute ACC for all ASG nodes	Fault-proneness estimates
3	Cluster ACCs and assign node weights	Critical, Moderate, Weak categories
4	Sum weights of covered nodes for each test case	Test-case weights
5	Sort by decreasing total test-case weight	Prioritized test suite

The test case total weight is given by

$n$0

where $n$1, $n$2, and $n$3 are the total weights of critical, moderate, and weak fault-prone nodes covered by test case $n$4 (Panda et al., 26 Aug 2025).

This procedure is static: it derives prioritization from dependency structure and coverage information rather than from dynamic fault histories. A plausible implication is that ACC is particularly relevant when historical failure data are sparse but a structural representation of the changed program is available.

6. Empirical findings and comparative performance

The empirical evaluation reported for ACC-based prioritization uses mutation testing to measure how quickly prioritized test cases detect faults. The analysis with mutation faults shows that test cases executing the fault-prone program parts have a higher chance to reveal faults earlier than other test cases in the test suite (Panda et al., 26 Aug 2025).

The reported results include several quantitative findings. On average, 47% of mutants resided in affected slices, and 85% of mutants in the affected slice were killed by prioritized tests. The average percentage of affected nodes covered by prioritized test cases using ACC was 80.6%, compared with 77.2% for the prior node-coverage-only approach. Average Percentage of Faults Detected (APFD) improved by about 8% over the baseline. High ACC nodes tended to be more fault-prone, so targeting them enabled earlier fault detection (Panda et al., 26 Aug 2025).

The abstract additionally states that the result obtained from seven case studies justifies that the approach is feasible and gives acceptable performance in comparison to some existing techniques (Panda et al., 26 Aug 2025). The details block separately states that programs tested were 15 Java object-oriented programs of various sizes. Since these two counts appear in different parts of the provided record, the safer reading is that the study reports multiple empirical analyses using mutation-based evaluation on Java object-oriented software, and that the reported findings support feasibility and acceptable comparative performance.

These findings support the specific claim that coupling within the affected slice is informative for prioritization. They do not establish that ACC is universally superior to all alternatives, but they do show that an ACC-based ordering can improve affected-node coverage and APFD relative to a node-coverage-only baseline (Panda et al., 26 Aug 2025).

7. Relation to broader coupling research and terminological ambiguity

ACC belongs to a broader family of coupling-based analyses in software engineering. Earlier work on interaction graphs and class coupling defines metrics such as NUCD, TNUCD, NUCC, TNUCC, Class Coupling, Client Coupling, Server Coupling, and Visible Member, with Class Coupling defined as the sum of Client Coupling and Server Coupling:

$n$5

where $n$6 is out-degree and $n$7 is in-degree in the interaction graph (Hasan et al., 2010). This earlier perspective emphasizes that low coupling improves maintainability, reusability, and software evolution, and proposes the Design Analyzer tool to parse Java source and visualize interactions (Hasan et al., 2010). ACC can be situated within this lineage as a change-specific, affected-region metric rather than a whole-class design metric.

At architecture level, a more recent quantitative framework models a system as a directed graph of couplings and treats ACC as the set of components or elements reachable from a changed interface via coupling edges. That framework provides graphical, algebraic, and tabular representations, and associates property values and cost factors with elements and couplings to bound change complexity and cost (Chan, 30 Jun 2026). In that setting, ACC is tied to propagation paths, cardinality of affected components, and aggregate path weights, extending the coupling concept beyond source code into system-level change estimation (Chan, 30 Jun 2026).

The acronym “ACC” is also used in unrelated arXiv literatures. In complexity theory, “ACC$n$8” denotes a family of Boolean circuits, and one result states that for each $n$9, NE has nonuniform ACC$n$0 circuits if and only if NE has $n$1-uniform ACC$n$2 circuits (Hemaspaandra, 2010). In birational geometry, “ACC” denotes the Ascending Chain Condition, as in results proving the ACC conjecture for local volumes (Han et al., 2024). These usages are terminologically unrelated to Affected Component Coupling and should not be conflated.

A common misconception is therefore to treat “ACC” as a single technical notion across fields. In software engineering, the term refers to affected coupling and change impact; in circuit complexity and algebraic geometry, it refers to different concepts entirely (Hemaspaandra, 2010, Han et al., 2024). Another misconception is to read ACC as a generic synonym for coupling. The software-testing formulation is narrower: it is impact-focused, ASG-based, and explicitly normalized by the number of affected nodes (Panda et al., 26 Aug 2025).