# Client-Library Compatibility Testing with API Interaction Snapshots

Gustave Monce, Thomas Degueule, Jean-Rémy Falleri, Romain Robbes

► To cite this version:

Gustave Monce, Thomas Degueule, Jean-Rémy Falleri, Romain Robbes. Client-Library Compatibility Testing with API Interaction Snapshots. 41st IEEE International Conference on Software Maintenance and Evolution (ICSME 2025), Sep 2025, Auckland, New Zealand. pp.791-796, 10.1109/IC-SME64153.2025.00081. hal-05188672

HAL Id: hal-05188672

https://hal.science/hal-05188672v1

Submitted on 27 Jul 2025

HAL is a multi-disciplinary open access
archive for the deposit and dissemination of sci-
entific research documents, whether they are pub-
lished or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.

L'archive ouverte pluridisciplinaire HAL, est
destinée au dépôt et à la diffusion de documents
scientifiques de niveau recherche, publiés ou non,
émanant des établissements d'enseignement et de
recherche français ou étrangers, des laboratoires
publics ou privés.

<figure><img src="image_1.png" /></figure>

Distributed under a Creative Commons Attribution 4.0 International License
# Client-Library Compatibility Testing with API Interaction Snapshots

Gustave Monce*, Thomas Degueule*, Jean-Rémy Falleri*† and Romain Robbes*

Univ. Bordeaux, CNRS, Bordeaux INP, LaBRI, UMR 5800, F-33400 Talence, France

*firstname.lastname@labri.fr

†Institut Universitaire de France

***Abstract***—Modern software development heavily relies on third-party libraries to speed up development and enhance quality. As libraries evolve, they may break the tacit contract established with their clients by introducing behavioral breaking changes (BBCs) that alter run-time behavior and silently break client applications without being detected at compile time. Traditional regression tests on the client side often fail to detect such BBCs, either due to limited library coverage or weak assertions that do not sufficiently exercise the library's expected behavior.

To address this issue, we propose a novel approach to client-library compatibility testing that leverages existing client tests in a novel way. Instead of relying on developer-written assertions, we propose recording the actual interactions at the API boundary during the execution of client tests (protocol, input and output values, exceptions, etc.). These sequences of API interactions are stored as *snapshots* which capture the exact contract expected by a client at a specific point in time. As the library evolves, we compare the original and new snapshots to identify perturbations in the contract, flag potential BBCs, and notify clients.

We implement this technique in our prototype tool GILESI, a Java framework that automatically instruments library APIs, records snapshots, and compares them. Through a preliminary case study on several client-library pairs with artificially seeded BBCs, we show that GILESI reliably detects BBCs missed by client test suites.

***Index Terms***—software library, evolution, compatibility

## I. INTRODUCTION

Modern software system development typically involves the use of third-party software libraries. Instead of creating new systems from scratch, developers incorporate libraries with desired functionalities into their projects. Application Programming Interfaces (APIs) govern the interactions between a library and its clients. Whenever a library evolves, however, it may break the contract previously established with its clients by introducing breaking changes. Breaking changes are either syntactic or semantic in nature [1]. Syntactic changes affect the API of a library, i.e., the signatures of exported symbols accessed from client code (types, methods, etc.). Semantic (or behavioral) changes affect the run-time behavior of a library and can alter client functionalities or trigger run-time errors.

These frictions at the boundary between clients and libraries have serious implications for both parties. Clients must be warned of potential changes that could impact them and must protect themselves from vulnerabilities and supply chain attacks [2]. Libraries must avoid carelessly breaking their clients to retain their trust and evolve gracefully [3]. While there has been significant work on the prevalence [4, 1],

detection [5, 6], and remediation [7, 8] of syntactic changes, behavioral breaking changes (BBCs) remain a challenge [9, 10]. Library tests—particularly regression tests—are well-suited to detect BBCs [11]. However, they are written by library maintainers and may not accurately reflect the actual usage of the library in the wild, which can differ significantly from the maintainers’ expectations [12, 13].

How can client projects ensure that changes introduced in a new library release will not affect them? Client developers naturally write regression tests to validate their own logic, which indirectly exercise the libraries upon which their logic is built. However, empirical evidence suggests that client tests are often too weak and ineffective in detecting BBCs introduced in library releases [14, 15, 16]. This can be caused by poor coverage of the library from the tests, weak assertions, and the significant distance between the tests and the exercised method in the library [17]. Approaches in the literature that tackle this problem either do not take into account how libraries are used in client code [18, 19], suffer from false positives [16], or adopt a crowd-sourced approach that assumes the existence of already migrated clients [19, 20].

In this paper, we propose a novel approach to leverage existing client tests and increase their ability to detect library BBCs. We propose to infer the behavioral contract between a client and a library by observing the interactions (protocol and values exchanged) at the API boundary between the client and the library while client tests are running. The sequence of interactions recorded during the execution of a test forms a *snapshot* that embodies the precise expectations of a healthy client towards the library at a given point in time. When the library is upgraded, the snapshots produced against the new library version can be compared against the original snapshots to detect differences in the interactions and report potential BBCs. As snapshots are recorded directly at the API boundary, they are more sensitive to potential perturbations in the library’s behavior and are more likely to catch BBCs than client tests.

We present GILESI, a prototype implementation of our approach for Java libraries.<fnref n="1" /> GILESI seamlessly instruments software libraries to record interaction snapshots during the execution of client tests and compare them when the library is upgraded. We showcase the capabilities of our approach and GILESI on an exploratory case study involving the popular

<footnote n="1">¹https://github.com/alien-tools/gilesi</footnote>
libraries JSOUP and COMMONS-LANG3, as well as 27 of their clients. We find that GILESI can detect artificial BBCs introduced in the libraries that are missed by client test suites.

## II. BACKGROUND AND MOTIVATION

Application Programming Interfaces (APIs) comprise a set of publicly accessible symbols—such as types, methods, and fields—that external code can access and interact with [13]. Clients, in turn, rely on these APIs to implement their own features, leveraging them by instantiating and extending types, accessing fields, invoking methods, etc.

Only a subset of the API exposed by a library is typically used in a particular client [16, 21]. This subset, the syntactic footprint [13], corresponds to the specific elements of the API on which the client depends. Breaking changes (BCs) in these elements can impact client code in diverse ways. Syntactic BCs (SBCs) affect the signature of these elements and manifest as compilation or linking errors, while behavioral BCs (BBCs) affect their run-time behavior and manifest as changed program state and values, run-time exceptions, or crashes [10, 22, 14]. SBCs have been extensively studied in the literature [4, 1] and can be detected automatically with good accuracy by static analysis tools [5]. Comparatively, BBCs have received little attention and are particularly insidious as they cannot be reliably detected statically [9].

Listing 1 depicts an example BBC introduced in common-text and reported in TEXT-219. The API method StringETY#getTokenList originally returns a list copy of an internal array of tokens. In commit 2d1ab7, released with version 1.10, a maintainer simplified various parts of the code and used the built-in utility `Arrays#asList` to convert the array into a list. This seemingly innocuous change introduced two adverse effects: the returned list implementation is now fixed-size, and it is backed by the original array, meaning that changing either will change the other. Thus, in contrast with the previous version, attempting to insert or remove an element in the returned list will raise a run-time exception, and reordering the list may have unintended side effects.

### A. Regression Testing

To mitigate the risks associated with BBCs, clients naturally write tests to validate their own logic, which indirectly exercises the logic of the APIs they use. In particular, developers use regression tests to ensure that changes do not unexpectedly alter their software's behavior [15, 11]. When libraries are updated to newer versions, these tests can sometimes catch BBCs introduced in the library and inform client developers [16, 14]. Executing the clients' test suites is also beneficial to library maintainers, as it can exercise their library in ways that they have not necessarily anticipated and catch regressions unseen by their own regression tests [15]. A popular implementation of this idea is GitHub's DEPENDABOT, which adopts a crowdsourced approach to run the CI and tests of client projects that have migrated to a new version and identify potentially unsafe upgrades.

Listing 1: An example BBC introduced in commons-text commit 2d1ab7. The regression was identified in TEXT-219 and later fixed in commit f9846b.

```java
public class StringETY
    ...
{
    public List<String> getTokenList() { // API 1.9
        List<String> list = new ArrayList<>(tokens.length);
        CollectionsAll(list, tokens);
        return list;
        // In 1.10, the entire method was replaced with
        return Arrays.asList(tokenS);
    } }

class Products { // Client code
    static List<String> fetchProducts(String products) {
        StringETY st = new StringETY.products);
        st.setDelimiterChar(');
        return stcheTokenList();
    }
}

class ProductsTest { // Client test
    @Test
    void test_fetchProducts() {
        String str = "apple,banana";
        List<String> fruits = Products.fetchProducts(str);
        assertEquals(2, fruits.size());
        assertThat(fruits, contains("apple", "banana"));
    }
}
```

But are client tests really effective in detecting BBCs in third-party libraries? In a large corpus of 8,086 Maven artifacts with passing test suites, Jayasuriya et al. find that upgrading their dependencies to the latest available version triggers test failures in only 2.3% of cases [14]. Gyori et al. find that 26.9% of libraries that can be updated in client projects result in test failures [15]. Hejderup and Gousios analyze 262 Java projects and find that client tests detect only 47% (resp. 35%) of artificial faults seeded in direct (resp. indirect) dependencies [16]. These empirical results suggest that existing client test suites are often too weak and ineffective in detecting BBCs in libraries.

Regression tests can fail to detect BBCs for two reasons: either they lack coverage and do not exercise the execution paths affected by BBCs, or their assertions are too weak to observe the change. Indeed, for BBCs to be detected, they must manifest at the API's boundary and propagate through client code up to a strong enough assertion that can observe the altered state. At each step, as the distance to change increases, lenient code can alter the observability of the change and reduce the likelihood of a failing assertion [17]. For instance, exception-swallowing code can prevent a newly raised exception from being detected by tests, or return values can simply be ignored. Subtle behavioral changes are particularly unlikely to be detected in this manner, leaving clients unaware of potential errors that may occur at run time. In Listing 1, although client tests accurately assert the behavior of the code relying on `StringETY#getTokenList`, they do not detect the regression. Other parts of the client that would attempt to alter the returned list might break as a result, and the developers would not be informed before the issue manifests at run time.

Interestingly, Jayasuriya et al. note that, even when BBCs do trigger test failures, the distance between the root cause of the error and the failing assertion severely hurts diagnosis and remediation [14]. To alleviate this issue, developers sometimes
write tests specifically to detect changes and regressions in the
behavior of the libraries they use. These tests directly exercise
the library's APIs—thus reducing distance and increasing
observability—and focus on verifying the expected outputs
and side effects. However, client tests are primarily concerned
with validating their own logic, and such library-focused tests
are relatively rare in practice.

## B. Dedicated Approaches

Several approaches have attempted to alleviate these issues
and to detect BBCs in software libraries more reliably. They
can be classified along three axes: (i) whether they consider the
entire API of a library or only the subset used by a particular
client, (ii) whether they exploit crowd-sourced knowledge from
other clients or can be applied to a single client immediately
after a release, and (iii) whether they rely on test execution or
static analysis of library changes.

SEMBID and DEBBI are two approaches aiming at detecting BBCs introduced in new library versions. SEMBID employs static analysis to compute semantic diffs between two API method versions and flag changes as potential BBCs [18]. DEBBI, on the other hand, adopts a crowd-sourced approach to aggregate the test suites of different clients using the same library [19]. As executing the resulting tests can be costly, DEBBI uses information retrieval techniques to prioritize the execution of test cases that are more likely to detect regressions in a given upgrade. While these approaches are beneficial for library maintainers who wish to avoid breaking any of their clients, they do not account for the specificity of particular clients that may tolerate BBCs that do not impact them.

UPPDATERA and COMPCHECK are two approaches aiming at detecting BBCs affecting a particular client. UPPDATERA is a client-specific approach that classifies changes in the methods reached by a particular client as regressions by identifying suspicious changes in control flow and dataflow using structural diffs between the two versions [16]. COMPCHECK is another client-specific approach that leverages crowd-sourced knowledge to generate incompatibility-revealing tests adapted from other clients using the library in a similar way [20]. While UPPDATERA sometimes produces false positives since the diff matching rules are too strict, COMPCHECK is guaranteed to produce true positives only with an accompanying test case. However, it may still suffer from false negatives when the generated assertions are too weak and not sensitive enough to detect the difference.

# III. APPROACH

Our hypothesis is that developers write test cases to exercise
important features and execution paths in their code. When
the implementation of these features relies on third-party code,
however, developer tests may not be able to properly assert
its behavior due to the distance between the test case and the
method it tests [17] and the difficulty of writing assertions on
code they do not own.

Our intuition is that BBCs introduced in libraries primarily
manifest as perturbations in the sequence of invocations

<figure><img src="image_2.png" /><figcaption>Fig. 1: Libraries expose their features through dedicated APIs. Clients use a subset of these APIs to implement their own features. For the sake of readability, only methods are depicted.</figcaption></figure>

(protocol) or values exchanged at the API boundary before
and after the change (Figure 1). These include return values,
in-out parameters, exceptions, or crashes. These perturbations
reflect deviations from the library's expected behavior but may
not always propagate far enough through client code to trigger
existing assertions. Nevertheless, they can still affect the client's
behavior and should be detected.

## A. Overview

To address this challenge, we propose an approach that
involves instrumenting and recording interactions at the API
boundary during the execution of client tests. When running a
client's test suite against a specific version of the library, we
capture these interactions and record them as snapshots, i.e.,
concrete traces that materialize the exact expectations of the
client towards the library at a given time. Inspired by snapshot
testing [23] and production monitoring techniques such as
PANKTI [24], snapshots document the behavioral contract
between a client and a library.

More precisely, each test case produces a snapshot *S*
represented as a sequence of API interactions. An interaction
$I = \langle m, o, \langle p_1, \dots, p_n \rangle, r \rangle$
records, for a particular API method *m*, the receiver object *o* on which the method is invoked, the list
of input values $p_i$ passed as arguments and the (typed) result of
its execution *r*—either a concrete value or an exception. For ex
ample, in Listing 1, the initial execution of the test first invokes
the client code depicted, which in turn invokes the API. The re
sulting snapshot for this test consists of a single API interaction
$S_1 = (\langle \text{getTokenList}, o_1, \emptyset, \text{ArrayList}(\text{apple}, \text{banana}) \rangle)$.

When the library is upgraded, we run the client's test
suite again and collect a new set of snapshots. The new
snapshots can be compared to those recorded with the previous
version to identify BBCs. Any difference between the original
and the new snapshots indicates a change in the library's
behavior. These discrepancies may arise from altered usage
protocols (when the order of method invocations differs) or
different return values (when an API produces a different or
exceptional result for the same inputs on the same object).
Since assertions are now evaluated at the API boundary, our
approach is more sensitive to subtle behavioral changes that
may not cause existing tests to fail, but still affect client logic.
This enables clients to detect and review behavioral changes,
even when those changes do not propagate to existing test
assertions. In Listing 1, when the API method is updated, the new snapshot consists of a single API interaction $S_2 = \langle \text{getTokenList}, o_1, \emptyset, \text{Arrays\$uhList}(\text{apple}, \text{banana}) \rangle$. Because $S_1 \neq S_2$, the two snapshots differ, and a BBC is reported for the method `getTokenList` in the new version.

Interestingly, our approach addresses three challenges typically faced in the detection of BBCs. First, it naturally captures reflective calls, as all method invocations are logged regardless of how they are dispatched. Second, it can detect changes in transitive dependencies as long as they propagate up to the API of a direct dependency to impact client code. More generally, it does not matter where the change is introduced as long as it propagates and can be observed at the API boundary manipulated by the client. Finally, snapshots explicitly document the exact behavior of the two library versions, making it easier to understand and debug BBCs.

## B. Instrumenting the API

As shown in Figure 1, only a subset of library code is typically exposed to clients through a dedicated API. In object-oriented languages like Java, this typically includes exported types, methods, and fields. BBCs, whether introduced in public or internal code, must eventually surface at the API boundary. Thus, a first step is to delimit the API of the library and the subset used in a particular client.

To target only the relevant API used by a given client, we extract a client-specific syntactic usage footprint using UCov [13], a lightweight static analysis tool. This enables us to focus on API symbols that can affect the client. These API symbols are then instrumented to log the values passed into and returned from each method during test execution. We use Java's instrumentation APIs in conjunction with Byte Buddy to implement a run-time agent that intercepts class loading events, identifies relevant method signatures (as determined by UCov), and injects probes at their entry and exit points. These probes are responsible for capturing the receiver object, input arguments, and return values. Aside from the added probes, the method's behavior remains unchanged.

## C. Recording & Comparing Snapshots

Once instrumentation is in place, running the client's test suite triggers the probes on each direct or indirect API call. The main challenge lies in serializing the observed values into stable snapshots that can be compared across library versions.

While serialization is straightforward for standard JDK types (e.g., primitives, collections), it becomes difficult for deeply nested or library-defined objects. We use the XSTREAM framework to serialize standard types. For complex objects, we defer serialization until additional method calls on them expose simpler, serializable data. For example, when the library returns a library-defined object, we record the interaction but only keep track of the object's identifier without attempting to serialize it. Then, we wait until other API methods are invoked on it and record those as well. The intuition here is that when the new API returns a different complex object, it cannot affect the client until concrete services are invoked.

Comparing snapshots first involves verifying that the ordering of interactions is identical between the old and new snapshots. When this is the case, interactions are compared pair-wise to verify that input and output values are the same. To match interactions, objects are given a unique identifier that allows tracing method invocations on the same objects throughout the execution.

# IV. CASE STUDY

In this section, we report on a preliminary case study of GILESI's ability to detect BBCs compared to client test suites. Our case study involves the Java libraries JSOUP and 6 of its clients as well as COMMONS-LANG3 and 21 of its clients. The data and notebooks discussed in this paper are available on Zenodo (https://doi.org/10.5281/zenodo.16411967).

## A. Protocol

As an initial sanity check, we first run the test suites of client projects against the original version of the libraries twice. Then, we filter out any client with failing or flaky test suites. We also record and store which API methods are reached during the execution of the tests.

To simulate the introduction of BBCs in these libraries, we implement another simple Java agent that dynamically introduces extreme mutations in API methods of interest. The agent removes all code in the original implementation and replaces it with a single return statement that returns a default value (null for reference types, zero for integers, etc.). This simulates a drastic change in behavior that should normally be caught by both client test suites and GILESI.

Then, we evaluate the ability of client test suites and GILESI to detect the introduced BBCs using a simple mutation score. First, we use GILESI to record the set of snapshots produced when running the client test suites against the original version of the libraries. We repeat this operation twice to ensure that GILESI produces stable snapshots and discard any test that yields flaky snapshots. Then, for each API method reached in client tests, we use the agent to insert the extreme mutations, one at a time, and run the client test suites another time. If any of the tests fail after introducing the mutation, then we consider that the client test suite successfully kills the mutant and detects the BBC. If any of the snapshots extracted after the mutation is introduced differ from the corresponding snapshot extracted on the original version of the library, then we consider that GILESI successfully detects the BBC and kills the mutant.

## B. Overall results

Table I presents the mutation scores obtained by client tests and GILESI following our protocol. Overall, GILESI detects 96% of the 158 mutants introduced in both libraries, while client test suites only detect 89% of them. All mutants killed by client tests are also killed by GILESI. Conversely, GILESI detects 10 extreme mutations missed by client tests.

However, there are still seven mutants that are not detected by GILESI. These cases stem from mutations that alter library-side I/O side effects without changing return values (e.g., on
<table><caption>TABLE I: Aggregated mutation scores.</caption><thead><tr><th rowspan="2">Library</th><th rowspan="2">Mutants</th><th colspan="2">Killed by</th></tr><tr><th>Tests</th><th>GILESI</th></tr></thead><tbody><tr><td>COMMONS-LANG3</td><td>106</td><td>100</td><td>105</td></tr><tr><td>JSOUP</td><td>52</td><td>41</td><td>46</td></tr></tbody></table>

void methods), or produce equivalent behavior because the original methods already return default values to all clients.

In this experiment, we rely on extreme mutations to simulate the introduction of BBCs. We hypothesize that finer-grained, classical mutation operators would be less likely to trigger test failures on the client side, while GILESI should retain much of its detection abilities, being closer to the seeded fault. Future experiments should thus further investigate how client tests and GILESI handle finer-grained mutations and real BBCs.

### C. Illustrative Cases

As part of our case study, we review two noteworthy cases that highlight how GILESI can help client developers protect themselves against library BBCs, including for clients with strong test suites.

1) **Case 1:** DEVOPS-COMDOR and COMMONS-LANG3: DEVOPS-COMDOR features functionality designed to help create issues on the code hosting platform GitHub. Part of the test suite of DEVOPS-COMDOR aims to test the creation of an issue when an exception is caught and to check whether the created issue contains correct information about such an exception. Information about the exception is extracted using the get bístackTrace method of COMMONS-LANG3 (Listing 2).

With the original version of the library, the issue is successfully created with the correct title and body. When running the same test on the mutated library, get bístackTrace no longer returns information about the exception. Thus, the created issue lacks crucial information. However, the corresponding test only asserts parts of the issue body and misses the introduced BBC. The client is thus vulnerable to future evolutions of COMMONS-LANG3 and may not detect potential regressions.

On the other hand, GILESI manages to catch the regression automatically. The original snapshot for this test identifies that get bístackTrace receives an I0Exception and produces a string describing the exception. The new snapshot produced after the mutation is introduced maps the exact same input to a different output, a null value. As the two snapshots differ, the BBC is detected and successfully reported to the user.

2) **Case 2:** CHYXION-TABLE-TO-XLS and JSOUP: CHYXION-TABLE-TO-XLS features functionality designed to turn an HTML document containing a table into an XLS spreadsheet. This client leverages several JSOUP features for parsing the HTML document, including attr to retrieve the string values of attributes.

In this example, the test verifies that a predefined HTML document can be successfully converted into a spreadsheet. Running the test against the original version of the library successfully creates a new spreadsheet with appropriate rows and columns. Running the test against the mutated version of

<figure><img src="image_3.png" /><figcaption>Listing 2: API, client code, and client test showcasing a missed BBC in DEVOPS-COMDOR</figcaption></figure>

the library, however, returns a spreadsheet with missing rows and columns. Indeed, the test merely verifies that the conversion runs successfully without crashes or exceptions, without asserting the shape of the returned spreadsheet. Therefore, the client is vulnerable to potential regressions in the evolution of JSOUP.

On the other hand, GILESI manages to catch the regression automatically. The snapshots produced with the original and mutated versions differ on multiple aspects. The first interaction with the attr method produces a different outcome, and the number of interactions differs. GILESI successfully catches the difference that can be reported to the client.

## V. CONCLUSION & RESEARCH ROADMAP

In this paper, we introduced a novel approach for detecting BBCs in software libraries by capturing API interaction snapshots during client test execution and comparing these snapshots across releases. Through a case study involving real-world libraries and clients, we showed that GILESI can identify BBCs missed by client test suites.

To realize the full potential of GILESI, future efforts should scale its evaluation across a broader set of libraries and involve finer-grained mutation operators or real releases, as well as account for the presence of nondeterminism, concurrency, and side effects. Addressing these limitations in future work will be critical to improving detection accuracy and enabling practical use by software developers.
REFERENCES

[1] D. Jayasuriya, S. Ou, S. Hegde, V. Terragni, J. Dietrich, and K. Blincoe, "An extended study of syntactic breaking changes in the wild," *Empir. Softw. Eng.*, vol. 30, no. 2, p. 42, 2025.

[2] P. Ladisa, S. E. Ponta, A. Sabetta, M. Martinez, and O. Barais, "Journey to the center of software supply chain attacks," *IEEE Secur. Priv.*, vol. 21, no. 6, pp. 34–49, 2023.

[3] C. Bogart, C. Kästner, J. D. Herbsleb, and F. Thung, "When and how to make breaking changes: Policies and practices in 18 open source software ecosystems," *ACM Trans. Softw. Eng. Methodol.*, vol. 30, no. 4, pp. 42:1–42:56, 2021.

[4] L. Ochoa, T. Degueule, J. Falleri, and J. J. Vinju, "Breaking bad? Semantic versioning and impact of breaking changes in Maven Central," *Empir. Softw. Eng.*, vol. 27, no. 3, p. 61, 2022.

[5] C. Latappy, T. Degueule, J.-R. Falleri, R. Robbes, and L. Ochoa, "Roseau: Fast, accurate, source-based breaking change analysis in Java," in *IEEE International Conference on Software Maintenance and Evolution, ICSME*. IEEE, 2025.

[6] A. Brito, L. Xavier, A. C. Hora, and M. T. Valente, "APIDiff: Detecting API breaking changes," in *25th International Conference on Software Analysis, Evolution and Reengineering, SANER*. IEEE Computer Society, 2018, pp. 507–511.

[7] X. Gao, A. Radhakrishna, G. Soares, R. Shariffdeen, S. Gulwani, and A. Roychoudhury, "APIfix: output-oriented program synthesis for combating breaking changes in libraries," *Proc. ACM Program. Lang.*, vol. 5, no. OOPSLA, pp. 1–27, 2021.

[8] H. Zhong and N. Meng, "Compiler-directed migrating API callsite of client code," in *Proceedings of the 46th IEEE/ACM International Conference on Software Engineering, ICSE*. ACM, 2024, pp. 226:1–226:12.

[9] L. Zhang, C. Liu, Z. Xu, S. Chen, L. Fan, B. Chen, and Y. Liu, "Has my release disobeyed semantic versioning? static detection based on semantic differencing," in *37th IEEE/ACM International Conference on Automated Software Engineering, ASE*. ACM, 2022, pp. 51:1–51:12.

[10] S. Mostafa, R. Rodriguez, and X. Wang, "Experience paper: a study on behavioral backward incompatibilities of Java software libraries," in *Proceedings of the 26th ACM SIGSOFT International Symposium on Software Testing and Analysis*. ACM, 2017, pp. 215–225.

[11] Y. Liu, J. Zhang, P. Nie, M. Gligoric, and O. Legunsen, "More precise regression test selection via reasoning about semantics-modifying changes," in *Proceedings of the 32nd ACM SIGSOFT International Symposium on Software Testing and Analysis, ISSTA*. ACM, 2023, pp. 664–676.

[12] I. Schittekat, M. Abdi, and S. Demeyer, "Can we increase the test-coverage in libraries using dependent projects'

test-suites?" in *EASE 2022: The International Conference on Evaluation and Assessment in Software Engineering*. ACM, 2022, pp. 294–298.

[13] G. Monce, T. Couturou, Y. Hamdaoui, T. Degueule, and J. Falleri, "Lightweight syntactic API usage analysis with UCov," in *Proceedings of the 32nd IEEE/ACM International Conference on Program Comprehension, ICPC*. ACM, 2024, pp. 426–437.

[14] D. Jayasuriya, V. Terragni, J. Dietrich, and K. Blincoe, "Understanding the impact of APIs behavioral breaking changes on client applications," *Proc. ACM Softw. Eng.*, vol. 1, no. FSE, pp. 1238–1261, 2024.

[15] A. Gyori, O. Legunsen, F. Hariri, and D. Marinov, "Evaluating regression test selection opportunities in a very large open-source ecosystem," in *2018 IEEE 29th International Symposium on Software Reliability Engineering (ISSRE)*. IEEE, 2018, pp. 112–122.

[16] J. Hejderup and G. Gousios, "Can we trust tests to automate dependency updates? A case study of java projects," *J. Syst. Softw.*, vol. 183, p. 111097, 2022.

[17] R. Niedermayr and S. Wagner, "Is the stack distance between test case and method correlated with test effectiveness?" in *Proceedings of the 23rd International Conference on Evaluation and Assessment in Software Engineering*, 2019, pp. 189–198.

[18] L. Zhang, C. Liu, Z. Xu, S. Chen, L. Fan, B. Chen, and Y. Liu, "Has my release disobeyed semantic versioning? static detection based on semantic differencing," in *Proceedings of the 37th IEEE/ACM International Conference on Automated Software Engineering*, 2022, pp. 1–12.

[19] L. Chen, F. Hassan, X. Wang, and L. Zhang, "Taming behavioral backward incompatibilities via cross-project testing and analysis," in *ICSE '20: 42nd International Conference on Software Engineering*, 2020, pp. 112–124.

[20] C. Zhu, M. Zhang, X. Wu, X. Xu, and Y. Li, "Client-specific upgrade compatibility checking via knowledge-guided discovery," *ACM Trans. Softw. Eng. Methodol.*, vol. 32, no. 4, pp. 98:1–98:31, 2023.

[21] N. Harrand, A. Benelallam, C. Soto-Valero, F. Bettega, O. Barais, and B. Baudry, "API beauty is in the eye of the clients: 2.2 million Maven dependencies reveal the spectrum of client-api usages," *J. Syst. Softw.*, vol. 184, p. 111134, 2022.

[22] F. Reyes, Y. Gamage, G. Skoglund, B. Baudry, and M. Monperrus, "BUMP: A benchmark of reproducible breaking dependency updates," in *IEEE International Conference on Software Analysis, Evolution and Reengineering, SANER*. IEEE, 2024, pp. 159–170.

[23] V. P. G. Cruz, H. Rocha, and M. T. Valente, "Snapshot testing in practice: Benefits and drawbacks," *J. Syst. Softw.*, vol. 204, p. 111797, 2023.

[24] D. Tiwari, L. Zhang, M. Monperrus, and B. Baudry, "Production Monitoring to Improve Test Suites," *IEEE Transactions on Reliability*, vol. 71, no. 3, 2022.