SearcharxivSearch

arXiv subjects

Rachna Raj

Publications and source records attributed to Rachna Raj.

4 recordsLinked to original sources

BreakGuard: Towards Detecting Dependency Breaking Changes with LLM-Generated Tests

Open-source libraries play an important role in software development by providing reusable features that expedite the development process. As libraries evolve, they release new versions that add features, fix bugs, or apply security patches. In this process, they may break the contract established with their clients by introducing breaking changes (BCs) that alter the runtime behavior and break client applications. Client-side test suites often fail to detect these BCs because of limited library coverage that does not exercise all library methods used in the client's codebase. We propose BreakGuard, an approach that generates a test suite to detect breaking changes in clients. BreakGuard statically extracts every client method (focal method) that invokes the target library method (call site), then generates tests per focal method. A test detects a BC if it passes on the pre-breaking version and fails on the breaking version. We evaluate our approach on 89 real-world breaking changes from the BUMP dataset, using 3 LLMs (GPT4o, Qwen3-coder-480B, GPT-OSS-120B) and three context levels: minimal, method, and class. Using the best-performing configuration, BreakGuard detects 30.3% of breaking changes (27 of 89) at a mean cost of roughly $0.90 USD per detected breaking change. We successfully detected BCs from different library categories (e.g., JSON libraries, logging, parsing), but we find LLM-generated tests to be more reliable for detecting crash-type breaking changes as opposed to behavioural BCs.

cs.SE

Beyond Compliance: A Large Scale Study on the Completeness and Consistency of the GitHub SBOMs

Modern software development relies heavily on open-source components. Reusing components accelerates innovation but increases exposure to supply-chain attacks exploiting known vulnerabilities. Software Bills of Materials (SBOMs) improve software supply chain transparency by enumerating components, their versions, and their provenance. GitHub, the largest open-source development hosting platform, now automatically generates SBOMs for repositories, providing valuable metadata for risk assessment. Yet, it is unclear whether GitHub SBOMs can serve as a reliable source for vulnerability and license analysis, and how incomplete or inconsistent metadata may affect different programming ecosystems. To address this, we conduct a large-scale analysis of 10,000 GitHub repositories across ten programming language ecosystems, evaluating GitHub SBOMs against three other popular SBOM generators: Syft, Trivy, and the Microsoft SBOM Tool. Our study finds a lack of NTIA compliance in GitHub SBOMs, though core metadata is consistently present. We also find that component version and license information availability is highly dependent on the programming ecosystem. Compared with the other three tools, GitHub yields results similar to the Microsoft SBOM Tool and often outperforms Syft and Trivy in providing version and license information. Finally, we discuss potential shortcomings of the GitHub SBOM Tool, directly related to how each ecosystem manages its dependencies.

cs.SE

Towards Supporting Open Source Library Maintainers with Community-Based Analytics

Open-source software (OSS) is a pillar of modern software development. Its success depends on the dedication of maintainers who work constantly to keep their libraries stable, adapt to changing needs, and support a growing community. Yet, they receive little to no continuous feedback on how the projects that rely on their libraries actually use their APIs. We believe that gaining these insights can help maintainers make better decisions, such as refining testing strategies, understanding the impact of changes, and guiding the evolution of their libraries more effectively. We propose the use of community-based analytics to analyze how an OSS library is used across its dependent ecosystem. We conduct an empirical study of 10 popular Java libraries and each with their respective dependent ecosystem of 50 projects. Our results reveal that while library developers offer a wide range of API methods, only 16% on average are actively used by their dependent ecosystem. Moreover, only 74% of the used API methods are partially or fully covered by their library test suite. We propose two metrics to help developers evaluate their test suite according to the APIs used by their community, and we conduct a survey on open-source practitioners to assess the practical value of these insights in guiding maintenance decisions.

cs.SE

The role of library versions in Developer-ChatGPT conversations

The latest breakthroughs in large language models (LLM) have empowered software development tools, such as ChatGPT, to aid developers in complex tasks. Developers use ChatGPT to write code, review code changes, and even debug their programs. In these interactions, ChatGPT often recommends code snippets that depend on external libraries. However, code from libraries changes over time, invalidating a once-correct code snippet and making it difficult to reuse recommended code. In this study, we analyze DevGPT, a dataset of more than 4,000 Developer-ChatGPT interactions, to understand the role of library versions in code-related conversations. We quantify how often library version constraints are mentioned in code-related conversations and when ChatGPT recommends the installation of specific libraries. Our findings show that, albeit to constantly recommend and analyze code with external dependencies, library version constraints only appear in 9% of the conversations. In the majority of conversations, the version constraints are prompted by users (as opposed to being specified by ChatGPT) as a method for receiving better quality responses. Moreover, we study how library version constraints are used in the conversation through qualitative methods, identifying several potential problems that warrant further research.

cs.SE